Почему вы должны предотвратить подкласс класса? - PullRequest
8 голосов
/ 24 августа 2008

Какие могут быть причины, препятствующие наследованию класса? (например, используя запечатанный на классе C #) Прямо сейчас я не могу думать ни о чем.

Ответы [ 14 ]

0 голосов
/ 24 августа 2008

Я представил минимальный интерфейс для взаимодействия с клиентским API, и было бы замечательно расширить класс клиентского API, а затем просто добавить предложение Implements с моим новым интерфейсом. Методы, которые у меня были в интерфейсе, который соответствовал фактическому интерфейсу, тогда не нуждались бы в дополнительных деталях, и поэтому мне не пришлось бы явно их реализовывать. Однако класс был запечатан, поэтому мне пришлось вместо этого использовать прокси-вызовы для внутренней ссылки на этот класс. Результат: больше работы и много кода без веской причины.

Ну, есть причина: ваш код теперь несколько изолирован от изменений в интерфейсе memcached.

0 голосов
/ 24 августа 2008

Не все, что важно в классе, легко утверждается в коде. Может присутствовать семантика и отношения, которые легко нарушаются путем наследования и переопределения методов. Переопределение одного метода за раз является простым способом сделать это. Вы проектируете класс / объект как одну значимую сущность, а затем кто-то приходит и думает, что если один или два метода «лучше», это не принесет вреда. Это может или не может быть правдой. Может быть, вы можете правильно разделить все методы между частными и не частными или виртуальными и не виртуальными, но этого все же может быть недостаточно. Требование наследования всех классов также накладывает огромное дополнительное бремя на первоначального разработчика, чтобы предвидеть все способы, которыми наследующий класс может испортить вещи.
Я не знаю идеального решения. Я сочувствую предотвращению наследования, но это также проблема, потому что это мешает юнит-тестированию.

0 голосов
/ 24 августа 2008

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

Примером, о котором я могу подумать сейчас, являются настроенные автономные классы с глубокими клонами в .Net. Если вы наследуете от них, вы теряете способность к глубокому клонированию. [Я немного неясен в этом примере, прошло много времени с тех пор, как я работал с IClonable] Если у вас есть настоящий класс Singelton, вы, вероятно, не хотите наследуемых форм это вокруг, и уровень персистентности данных обычно не место, где вы хотите много наследования.

0 голосов
/ 24 августа 2008

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

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

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

Или, может быть, нет смысла (что вы видите сейчас) иметь подкласс.

Или вам не нужны отчеты об ошибках, когда люди пытаются создать подкласс и им не удается получить все мелкие детали - сократить расходы на поддержку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...