反对在接口上声明受保护的访问成员的论点是什么?例如,这是无效的:
public interface IOrange
{
public OrangePeel Peel { get; }
protected OrangePips Seeds { get; }
}
在这个例子中,接口IOrange
将保证实现者至少OrangePips
向他们的继承者提供一个实例。如果实施者愿意,他们可以将范围扩大到 full 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;
...
}
(诚然,这对 s 不起作用struct
)
我在接口中看不到private
orinternal
修饰符的太多情况,但同时支持public
andprotected
修饰符似乎是完全合理的。
我将尝试通过将成员与s 完全分开来解释protected
成员在s 上的效用:interface
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
成员的类——这不是我们目前可以做的事情。