在c#中隐式和显式实现接口有什么不同?
什么时候用隐式,什么时候用显式?
这两者之间有什么利弊吗?
微软的官方指南(来自第一版框架设计指南)指出,不建议使用显式实现,因为它会给代码带来意想不到的行为。
我认为这个准则在前ioc时代是非常有效的,当你不把东西作为接口传递的时候。
有人能谈谈这方面的问题吗?
在c#中隐式和显式实现接口有什么不同?
什么时候用隐式,什么时候用显式?
这两者之间有什么利弊吗?
微软的官方指南(来自第一版框架设计指南)指出,不建议使用显式实现,因为它会给代码带来意想不到的行为。
我认为这个准则在前ioc时代是非常有效的,当你不把东西作为接口传递的时候。
有人能谈谈这方面的问题吗?
当前回答
实现接口的每个类成员都导出一个语义上类似于VB的声明。NET接口声明被编写,例如:
Public Overridable Function Foo() As Integer Implements IFoo.Foo
尽管类成员的名称经常与接口成员的名称相匹配,而且类成员通常是public的,但这些都不是必需的。你也可以声明:
Protected Overridable Function IFoo_Foo() As Integer Implements IFoo.Foo
In which case the class and its derivatives would be allowed to access a class member using the name IFoo_Foo, but the outside world would only be able to access that particular member by casting to IFoo. Such an approach is often good in cases where an interface method will have specified behavior on all implementations, but useful behavior on only some [e.g. the specified behavior for a read-only collection's IList<T>.Add method is to throw NotSupportedException]. Unfortunately, the only proper way to implement the interface in C# is:
int IFoo.Foo() { return IFoo_Foo(); }
protected virtual int IFoo_Foo() { ... real code goes here ... }
没那么好。
其他回答
前面的回答解释了为什么用c#显式地实现接口可能更可取(主要是出于形式上的原因)。然而,有一种情况下显式实现是强制的:为了避免在接口是非公共的,但实现类是公共的情况下泄露封装。
// Given:
internal interface I { void M(); }
// Then explicit implementation correctly observes encapsulation of I:
// Both ((I)CExplicit).M and CExplicit.M are accessible only internally.
public class CExplicit: I { void I.M() { } }
// However, implicit implementation breaks encapsulation of I, because
// ((I)CImplicit).M is only accessible internally, while CImplicit.M is accessible publicly.
public class CImplicit: I { public void M() { } }
上述泄漏是不可避免的,因为根据c#规范,“所有接口成员隐式地具有公共访问权限”。因此,隐式实现也必须提供公共访问,即使接口本身是内部的。
c#中的隐式接口实现非常方便。在实践中,许多程序员一直在使用它,而没有进一步考虑。这在最好的情况下会导致混乱的类型表面,在最坏的情况下会导致泄漏封装。其他语言,比如f#,甚至不允许这样做。
隐式定义是将接口需要的方法/属性等直接作为公共方法添加到类中。
显式定义强制只在直接使用接口而不是底层实现时才公开成员。在大多数情况下,这是首选。
By working directly with the interface, you are not acknowledging, and coupling your code to the underlying implementation. In the event that you already have, say, a public property Name in your code and you want to implement an interface that also has a Name property, doing it explicitly will keep the two separate. Even if they were doing the same thing I'd still delegate the explicit call to the Name property. You never know, you may want to change how Name works for the normal class and how Name, the interface property works later on. If you implement an interface implicitly then your class now exposes new behaviours that might only be relevant to a client of the interface and it means you aren't keeping your classes succinct enough (my opinion).
隐式是指通过类上的成员定义接口。显式是指在接口上的类中定义方法。我知道这听起来令人困惑,但我的意思是:IList。CopyTo将隐式实现为:
public void CopyTo(Array array, int index)
{
throw new NotImplementedException();
}
并明确为:
void ICollection.CopyTo(Array array, int index)
{
throw new NotImplementedException();
}
不同之处在于,隐式实现允许您通过创建的类访问接口,方法是将接口转换为该类和接口本身。显式实现允许您仅通过将接口转换为接口本身来访问接口。
MyClass myClass = new MyClass(); // Declared as concrete class
myclass.CopyTo //invalid with explicit
((IList)myClass).CopyTo //valid with explicit.
我使用显式主要是为了保持实现的简洁,或者当我需要两个实现时。不管怎样,我很少使用它。
我相信有更多的理由使用/不使用explicit,其他人会发布。
请参阅本帖的下一篇文章,了解每一篇文章背后的优秀推理。
隐式接口实现是指具有与接口相同签名的方法。
显式接口实现是显式声明方法属于哪个接口的地方。
interface I1
{
void implicitExample();
}
interface I2
{
void explicitExample();
}
class C : I1, I2
{
void implicitExample()
{
Console.WriteLine("I1.implicitExample()");
}
void I2.explicitExample()
{
Console.WriteLine("I2.explicitExample()");
}
}
MSDN:隐式和显式接口实现
我发现自己最近更经常地使用显式实现,原因如下:
Always using explicit from the starts prevents having any naming collisions, in which explicit implementation would be required anyways Consumers are "forced" to use the interface instead of the implementation (aka not "programming to an implementation") which they should / must do anyways when you're using DI No "zombie" members in the implementations - removing any member from the interface declaration will result in compiler errors if not removed from the implementation too Default values for optional parameters, as well constraints on generic arguments are automatically adopted - no need to write them twice and keep them in sync