为什么我不能有保护的接口成员？ [英] Why can't I have protected interface members?

问题描述

什么是对，宣布保护成员的访问接口上的说法？此，例如，无效：

What is the argument against declaring protected-access members on interfaces? This, for example, is invalid:

public interface IOrange
{
    public OrangePeel Peel { get; }
    protected OrangePips Seeds { get; }
}

在这个例子中，接口 IOrange 将保证实现者的至少的提供了一个 OrangePips 例如他们的继承者。如果实现者愿意，他们可以扩大范围到全公共：

In this example, the interface IOrange would guarantee that implementors at least provide an OrangePips instance to their inheritors. If the implementor wanted to, they could expand the scope to 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); } }
}

保护成员对接口的目的是为的继承的（子类）提供了支持合同，例如：

The intent of protected members on interfaces is to provide a support contract for inheritors (sub-classes), for example:

public class SpecialNavelOrange : NavelOrange
{
    ...
    // Having a seed value is useful to me.
    OrangePips seeds = this.Seeds; 
    ...
}

（诚然，这不会为<$​​ C $ C>结构作品）

我看不出太大的情况下为私人或内部修饰符接口，但同时支持公共和保护修饰符似乎完全合理的。

I can't see much of a case for private or internal modifiers in interfaces, but supporting both public and protected modifiers seems perfectly reasonable.

---

我要通过<$分开来尝试解释接口 S于保护成员的效用C $ C>接口真完全：

I'm going to try explaining the utility of protected members on interfaces by separating them from interfaces entirely:

让我们想象一下一个新的C＃的关键字，支持，强制执行合同的传承，让我们申报物品如下：

Let's imagine a new C# keyword, support, to enforce inheritor contracts, so that we declare things as follows:

public support IOrangeSupport
{
    OrangePips Seeds { get; }
}

这将允许我们签约的类来提供保护成员自己的继承人：

This would allows us to contract classes to provide protected members to their inheritors:

public class NavelOrange : IOrange, IOrangeSupport
{
    public OrangePeel Peel { get { return new OrangePeel(); } }
    protected OrangePips Seeds { get { return null; } }
}

这是不是特别有用，因为班会已经在第一时间提供保护成员暗示本合同。

This is not particularly useful, because classes would already imply this contract by providing the protected members in the first place.

不过，那么我们也可以这样做：

But then we could also do this:

public interface IOrange : IOrangeSupport
{
   ...
}

由此将 IOrangeSupport 到实施 IOrange 所有类，并要求他们提供特定的保护成员 - 这不是我们目前可以做一些事情。

Thereby applying IOrangeSupport to all classes which implement IOrange and requiring them to provide particular protected members - which is not something we can currently do.

推荐答案

我想每个人都敲定只具有公共成员，没有实施细则的接口点。你要找的是一个抽象类。

I think everyone hammered the point of an interface having only public members, no implementation details. What you are looking for is an abstract class.

public interface IOrange
{
    OrangePeel Peel { get; }
}

public abstract class OrangeBase : IOrange
{
    protected OrangeBase() {}
    protected abstract OrangePips Seeds { get; }
    public abstract OrangePeel Peel { get; }
}

public class NavelOrange : OrangeBase
{
    public override OrangePeel Peel { get { return new OrangePeel(); } }
    protected override OrangePips Seeds { get { return null; } }
}

public class ValenciaOrange : OrangeBase
{
    public override OrangePeel Peel { get { return new OrangePeel(); } }
    protected override OrangePips Seeds { get { return new OrangePips(6); } }
}

编辑：公平地说，如果我们有一个从一个类饰品派生的PlasticOrange，它只能实现IOrange，而不是种子的保护方法。没事儿。通过定义一个接口是呼叫者和对象之间的合同，而不是一个类及其子类之间。抽象类是接近我们来到了这个概念。这是罚款。你基本上建议是，通过它我们可以从一个基类的子类切换到另一个不破坏构建的另一种语言结构。对我来说，这是没有意义的。

It is fair to argue that if we have a PlasticOrange that derives from a class Ornament, it can only implement IOrange and not the Seeds protected method. That is fine. An interface by definition is a contract between a caller and an object, not between a class and its subclasses. The abstract class is as close as we come to this concept. And that is fine. What you are essentially proposing is another construct in the language through which we can switch subclasses from one base class to another without breaking the build. To me, this doesn't make sense.

如果你正在创建一个类的子类，子类是基类的一个特例。应该充分认识到基类的任何保护成员的。但是，如果你突然想转基类的，它是没有意义的子类都应该与任何其他IOrange工作。

If you are creating a subclass of a class, the subclass is a specialization of the base class. It should be fully aware of any protected members of the base class. But if you suddenly want to switch the base class out, it makes no sense that the subclass should work with any other IOrange.

我假设你有一个公平的问题，但它似乎是一个角落的情况下，我没有看到它的任何利益是诚实的。

I suppose you have a fair question, but it seems like a corner case and I don't see any benefit from it to be honest.

这篇关于为什么我不能有保护的接口成员？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！