Почему интерфейсы не могут быть помечены как запечатанные?

public sealed interface IMyInterface
{
}

Дает "Измененный" запечатан "недействителен для этого элемента"

Я каким-то образом понимаю, что интерфейс должен быть descendable, иначе класс не сможет его реализовать.

Но почему я не могу указать, что интерфейс не должен иметь определенный интерфейс или есть способ, просто не с sealed?

Edit

Я должен был приложить некоторые усилия, чтобы объяснить, почему я хочу этого. Я часто вижу цепи наследования интерфейсов, где разработчик должен использовать композицию. Sealed идеально подходит для этого в классах, и я задавался вопросом, существует ли способ обеспечить их соответствие интерфейсам. Поскольку unnessasary наследование затрудняет реорганизацию и поддержку, на мой взгляд.

Изменить 2

При отражении комментариев и сообщений деревья наследования интерфейсов не могут быть нигде не такими сложными, как деревья наследования объектов. Как и при выводе из другого интерфейса IX, все, что вы говорите, должно "также реализовать IX". И предотвращать это не имеет никакой пользы.

Ответ 1

Целью герметизации класса или виртуального метода класса является снижение затрат. Проектирование для наследования является дорогостоящим, и если вы не сделаете это правильно, это опасно. Есть последствия безопасности, правильности и надежности для ненадлежащего проектирования для наследования, поэтому, если вы не собираетесь создавать для наследования, целесообразно запечатать ваш класс и тем самым избежать затрат, связанных с проектированием для наследования.

Классы должны быть предназначены для наследования, потому что у них есть детали реализации. Интерфейсы не имеют деталей реализации. Нет никаких затрат, связанных с наследуемыми интерфейсами. И поэтому нет стимула добавлять функцию разрешения интерфейсов.

Ответ 2

Это просто сбивает с толку. Используя стандартный синтаксис, это означает, что вы не можете реализовать интерфейс. Кроме того, интерфейсы не содержат каких-либо функциональных возможностей или полей, поэтому практического использования при его герметизации нет. Интерфейс - это более или менее контракт.

Уплотнение интерфейса от "наследования интерфейса" ничего не сделало бы, так как люди могли бы просто реализовать ваш интерфейс, а другой - унаследовать ваш интерфейс.

Ответ 3

sealed в контексте интерфейса означает, что ни один класс не может реализовать этот интерфейс. Это было бы бесполезно, поэтому его не допускали.

Ответ 4

Ключевое слово sealed просто не предназначено (и не имеет смысла) для интерфейсов. См. Документацию msdn http://msdn.microsoft.com/en-us/library/88c54tsw(v=vs.71).aspx

Ответ 5

Запечатанный - это ключевое слово для класса. Цель интерфейсов заключается в том, чтобы классы выполняли любые контракты, которые они определяют. Вы можете запечатать класс, который реализует интерфейс, но уплотнение интерфейса было бы малопривлекательным.

Ответ 6

Интерфейсы - это ваш контракт на приложение... Когда вам не нужен ваш контракт, почему вы его определяете?

Ответ 7

Одна из основных целей герметизации класса - потребовать от любых мест хранения этого класса хранения экземпляров этого точного типа, а не производного типа. Несмотря на то, что большинство кодов не будут возражать, если объекты базового типа заменяются объектами базового типа, существует множество ситуаций, когда такая замена может быть проблематичной. Например, некоторые классы включают функцию для выполнения относительного сравнения с другим объектом того же типа с ожиданием, что результаты сравнения приведут к сортируемой последовательности. Если типы Bar и Boz получаются из Foo и используют любые Bar -специфические или Boz -специфические поля в сравнении, может быть невозможно упорядочить сортировку последовательностей, содержащих смесь Bar и Boz.

Такая цель не будет существовать с интерфейсами, поскольку по своим интерфейсам природы предназначены для реализации несколькими классами. Интерфейс, который не может быть реализован ни одним классом, бесполезен, и интерфейс, который может быть реализован только одним классом, будет бессмысленным (если IFoo не может быть чем-то другим, кроме Foo), можно было бы просто используйте Foo, где каждый будет склонен использовать IFoo).

Было бы полезно ограничить реализацию интерфейса с модулем, где он был определен, и/или позволить интерфейсам иметь internal членов. Я не знаю какой-либо особой причины, почему это не разрешено, и даже если разрешать или запрещать такие вещи было бы "легче" или "сложнее", чем запрещать их.

Ответ 8

Для меня interface подразумевает abstract ключевое слово; поэтому, если интерфейс будет sealed, это будет sealed abstract, что кажется противоречием.