反对在接口上声明 protected-access 成员的理由是什么? 例如,这是无效的:
public interface IOrange
{
public OrangePeel Peel { get; }
protected OrangePips Seeds { get; }
}
在本例中,接口 IOrange
将保证实现者 至少向其继承者提供一个 OrangePips
实例。如果实施者愿意,他们可以将范围扩大到完整的 public
:
public class NavelOrange : IOrange
{
public OrangePeel Peel { get { return new OrangePeel(); } }
protected OrangePips Seeds { get { return null; } }
}
public class ValenciaOrange : IOrange
{
public OrangePeel Peel { get { return new OrangePeel(); } }
public OrangePips Seeds { get { return new OrangePips(6); } }
}
protected
成员在接口上的意图是为 继承人(子类)提供一个支持契约,例如:
public class SpecialNavelOrange : NavelOrange
{
...
// Having a seed value is useful to me.
OrangePips seeds = this.Seeds;
...
}
(不可否认,这对 struct
s 不起作用)
我看不出在接口中有多少 private
或 internal
修饰符的情况,但是同时支持 public
和 protected
修饰符似乎是完全合理的。
我将尝试通过将 protected
成员与 interface
成员完全分开来解释 protected
成员在 interface
上的作用:
让我们设想一个新的 C # 关键字 support
来强制执行继承者契约,这样我们就可以像下面这样声明:
public support IOrangeSupport
{
OrangePips Seeds { get; }
}
这将允许我们对类进行契约,以便为其继承者提供受保护的成员:
public class NavelOrange : IOrange, IOrangeSupport
{
public OrangePeel Peel { get { return new OrangePeel(); } }
protected OrangePips Seeds { get { return null; } }
}
这并不特别有用,因为类首先通过提供 protected
成员已经暗示了这个约定。
但是我们也可以这样做:
public interface IOrange : IOrangeSupport
{
...
}
因此,将 IOrangeSupport
应用到所有实现 IOrange
的类,并要求它们提供特定的 protected
成员——这是我们目前无法做到的。