Одна из основных целей запечатывания класса - требовать, чтобы в любых местах хранения этого класса содержались экземпляры этого точного типа, а не производного типа.Несмотря на то, что большая часть кода не будет возражать, когда объекты производного типа заменяются объектами базового типа, во многих случаях такая замена может быть проблематичной.Например, некоторые классы включают функцию для выполнения относительного сравнения с другим объектом того же типа, ожидая, что результаты сравнения приведут к сортируемой последовательности.Если типы Bar
и Boz
являются производными от Foo
и используют для сравнения любые Bar
-специфичные или Boz
-специфичные поля, может оказаться невозможным разумно отсортировать последовательности, содержащие смесь Bar
и Boz
экземпляров.
Такая цель не будет существовать с интерфейсами, поскольку по своей природе интерфейсы предназначены для реализации несколькими классами.Интерфейс, который не может быть реализован какими-либо классами, был бы бесполезен, а интерфейс, который мог бы быть реализован только одним классом, был бы бессмысленным (если IFoo
не может быть ничем иным, чем Foo
, можно такжепросто используйте Foo
везде, где каждый будет склонен использовать IFoo
).
Было бы полезно ограничить реализацию интерфейса модулем, в котором он определен, и / или позволить интерфейсам иметь internal
участники.Я не знаю какой-либо конкретной причины, по которой это не разрешено, и даже того, было бы разрешать или запрещать такие вещи «проще» или «сложнее», чем запрещать их.