Может быть отменено переопределение?

Question

Существует принцип проектирования, который гласит: Состав предпочтения по сравнению с наследованием , и его рекламируемое преимущество заключается в том, что оно упрощает проектирование . Давайте договоримся об этом в качестве фона для этого вопроса.

Так, может ли переопределение быть устаревшим? Можем ли мы теоретически избавиться от этого навсегда?

Давайте немного усердствуем над вышеупомянутым принципом дизайна и доведем его до крайности: всю композицию. Одной причины на данный момент должно быть достаточно: переопределить злоупотребление .

Возникает один вопрос: мы, программисты, собираемся что-то потерять? Потеряна ли какая-либо сила, чтобы предотвратить возможные злоупотребления?

Итак, какие приложения существуют для переопределения и могут ли они быть достигнуты в противном случае? Должны ли они?

Answer 1

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

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

И я не согласен с основным предположением, что любое использование override является неуместным или оскорбительным. Есть много случаев, когда вы хотите воспользоваться наследованием, подразумевающим отношения is-a . Конечно, эта модель не соответствует реальному миру 100% времени, но есть много раз, что она делает.

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

Это не значит, что я не согласен с мнением о том, что в целом или, если сомневаешься, отдавать предпочтение композиции, а не наследованию. Но это не говорит о том, что наследование это плохо и никогда не должно использоваться.

Answer 2

Если вы полностью удалите наследование, вы удалите существенную особенность дизайна ООП.
Использование наследования позволяет вам использовать дизайн " is ", который имеет сильное значение в дизайне ООП, икурс сохраняет избыточность кода.

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

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

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

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

Answer 3

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

В этой дискуссии может быть языковой компонент.Когда я пишу на Java, я делаю подкласс с бешеной скоростью.Когда я пишу на C #, я долго и усердно думаю, прежде чем что-то переопределять или даже использовать интерфейсы.Я не уверен, почему, и это может быть больше связано с типом работы, которую я делаю на этих языках, чем сами языки.Но работая в C #, я весьма сочувствую этой идее, хотя при работе в Java ... ну, мне бы пришлось бросить почти весь мой код Java, если я не мог переопределить.

Answer 4

Я добавил ответ от имени astander , извлекая из его ссылку (надеюсь, вы не против)

Например, одинПреимущество наследования заключается в том, что его проще использовать, чем композицию.Однако такая простота использования достигается за счет того, что его труднее использовать повторно, поскольку подкласс привязан к родительскому классу.

Одним из преимуществ композиции является то, что она более гибкая, поскольку поведение можно менять во время выполнения.Одним из недостатков композиции является то, что поведение системы может быть сложнее понять, просто взглянув на источник.Это все факторы, которые следует учитывать при применении композиции к наследованию.