C# - 实现具有两个公共接口的私有类，然后转换为它们两个？坏主意？
这被认为是个好主意吗？将同一个类类型转换为它实现的两个不同接口。我认为这是个好主意..但我不确定。
public interface Abc
{
int xyz { get; }
}
public interface Xyz
{
int abc { get; }
}
internal class MyClass : Abc, Xyz
{
public int xyz
{
get
{
return 0;
}
}
public int abc
{
get
{
return 1;
}
}
}
var myclass = new MyClass();
var abc = myclass as Abc;
var xyz = myclass as Xyz;
Is this considered a good idea? Type casting the same class to two different interfaces it implements. I think it's a good idea .. but am not sure.
public interface Abc
{
int xyz { get; }
}
public interface Xyz
{
int abc { get; }
}
internal class MyClass : Abc, Xyz
{
public int xyz
{
get
{
return 0;
}
}
public int abc
{
get
{
return 1;
}
}
}
var myclass = new MyClass();
var abc = myclass as Abc;
var xyz = myclass as Xyz;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果它实现了该接口，则无需对其进行强制转换。
使用界面中的属性。
If it implements the interface, you will not need to cast it.
Use the properties from the interface.
我认为这是引入接口的原因之一。使用接口时，最终你并不关心哪个具体类实现了它，只要它正确地实现了这个接口即可。
另外，你不需要投射。实现接口的类和该接口的变量的赋值是隐式的。
I think this is one of the reasons, why interfaces got introduced. When using interface, in the end, you don't care about which concrete class implements it, as long as it implements this interface correctly.
Also, you don't need to cast. The assignment of class implementing interface and variable of this interface is implicit.
是的，这是一个好主意，特别是当您的班级扮演不同的角色时。 Abc 和 Xyz 可能不是最好的例子，但像 ICanValidate、IHaveDefault、IHaveAnEngine 等可能更好:)
这种设计的亮点在于某些功能是可选的。以 ICanValidate 为例：在持久化管道中的某个位置，您安全将实体转换为 ICanValidate。如果它返回 null 那么你忽略它；但是，如果它返回接口，您可以调用
entity.IsValid()。只是关于铸造的注释。一些答案指出，实现接口时不需要进行强制转换。这对于隐式实现来说是正确的——对于显式实现，您将需要强制转换。但我想这会相当明显:)
Yes it is a good idea, especially if your classes are fulfilling different roles. Abc and Xyz may not be the best examples but something like ICanValidate, IHaveDefault, IHaveAnEngine, etc. may be better :)
Where such a design shines is when certain functionality is optional. Take the ICanValidate example: somewhere in your persistence pipeline you safe cast your entity to ICanValidate. If it returns null then you ignore it; however, if it returns the interface you can call
entity.IsValid().Just a note on casting. Some answers have stated that you don't need to cast when an interface is implemented. This is true for implicit implementation --- for explicit implimentation you will require casting. But I guess that would be rather obvious :)
不存在类型转换的好坏问题，
对于前。 List 正在实现 IList 和 IEnumerable。
当列表上需要迭代时使用 IEnumerable，
当需要执行列表操作（如添加项目）时，需要使用 IList。
所以这取决于您需要的功能（来自哪个界面）。
当接口由类实现时，也不需要 CASTING。
There is no question about good or bad to type casting,
For ex. List is implementing IList and IEnumerable.
when iteration is required on list IEnumerable is used,
and when list operation (like Add item ) need to be performed IList need to be used.
so it depends on functionality (from which interface) you need.
Also you do not need CASTING when interface is implemented by class.
首先。如果您希望其他人使用您的代码，您应该真正遵循 开发类库的设计指南。看起来您正在使用 Java 中使用的命名准则。
进行内部操作的唯一原因是防止其他人创建该类。尽管使用反射仍然是可能的。除此之外，没有任何理由。如果您不希望其他人扩展您的类，只需将其
密封即可。但你也应该有一个很好的理由。最后，从使用的角度来看，您的方法没有任何问题。任何代码都不应该关心接口实现的外观或它的保护程度。每个用户应该只关心它有一个接口实现的实例。
First of all. If you want others to use your code you should really follow the Design Guidelines for Developing Class Libraries. It looks like you are using naming guidelines used in Java.
The only reason to make something internal is to prevent others from creating the class. It's still possible though using reflection. Other than that, theres no reason. If you do not want others to extend your class, simply make it
sealed. But you should have a really good reason for that too.Finally there is nothing wrong with your approach looking from a usage perspective. No code should care how the interface implementation looks like or how protected it is. Each user should only care in that it has an instance to an interface implementation.