インターフェイスで保護されたアクセスメンバーを宣言することに反対する議論は何ですか？たとえば、これは無効です。
public interface IOrange
{
public OrangePeel Peel { get; }
protected OrangePips Seeds { get; }
}
この例では、インターフェースは、実装者が少なくとも継承者にインスタンスを提供するIOrangeことを保証します。実装者が望む場合は、スコープを完全に拡張できます。OrangePipspublic
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または修飾子のケースの多くはわかりませんが、と修飾子の両方をサポートすることは完全に合理的であるように思われます。internalpublicprotected
メンバーをsから完全に分離することにより、sのprotectedメンバーの有用性を説明してみます。interfaceinterface
継承者のコントラクトを適用するための新しい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ます。これは、現在私たちができることではありません。