Каков аргумент против объявления элементов защищенного доступа на интерфейсах? Это, например, недействительно:
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
, полностью отделив их от interface
:
Представьте себе новое ключевое слово С#, 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
- которые мы не можем сейчас делать.