当成员在上下文中毫无意义时,这样做是一种很好的形式。例如,如果您创建一个只读集合,该集合IList<T>
通过委派给一个内部对象来实现,_wrapped
则您可能会遇到以下情况:
public T this[int index]
{
get
{
return _wrapped[index];
}
}
T IList<T>.this[int index]
{
get
{
return this[index];
}
set
{
throw new NotSupportedException("Collection is read-only.");
}
}
public int Count
{
get { return _wrapped.Count; }
}
bool ICollection<T>.IsReadOnly
{
get
{
return true;
}
}
在这里,我们有四种不同的情况。
public T this[int index]
是由我们的类而不是接口定义的,因此当然不是显式的实现,尽管请注意,它的确T this[int index]
与接口中定义的读写相似,但是是只读的。
T IList<T>.this[int index]
之所以是明确的,是因为其中的一部分(getter)与上面的属性完全匹配,而另一部分将始终引发异常。尽管对于通过接口访问此类实例的用户至关重要,但对于通过此类类型的变量使用此类实例的用户而言却毫无意义。
同样,因为bool ICollection<T>.IsReadOnly
总是要返回true,所以针对类的类型编写的代码完全没有意义,但是对于通过接口的类型使用它至关重要,因此我们明确实现了它。
相反,public int Count
未明确实现,因为它可能对通过自己的类型使用实例的某人有用。
但是对于您的“很少使用”情况,我确实非常倾向于不使用显式实现。
在我建议使用显式实现的情况下,通过类类型的变量调用该方法可能是错误(试图使用索引的setter)或毫无意义(检查将始终相同的值),因此隐藏它们可以保护用户免受错误或次优代码的侵害。这与您认为很少使用的代码有很大不同。为此,我可能会考虑使用该EditorBrowsable
属性将成员从智能感知中隐藏起来,尽管我会感到厌倦。人们的大脑已经拥有自己的软件,可以过滤掉他们不感兴趣的内容。