Почему интерфейсы не могут быть помечены как закрытые? - PullRequest
17 голосов
/ 27 марта 2012
public sealed interface IMyInterface
{
}

Дает «Модифицированный« запечатанный »недействителен для этого элемента»

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

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

Редактировать

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

Редактировать 2

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

Ответы [ 8 ]

19 голосов
/ 27 марта 2012

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

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

12 голосов
/ 27 марта 2012

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

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

4 голосов
/ 27 марта 2012

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

1 голос
/ 27 марта 2012

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

1 голос
/ 27 марта 2012

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

0 голосов
/ 28 марта 2012

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

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

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

0 голосов
/ 27 марта 2012

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

0 голосов
/ 27 марта 2012

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

...