Как отказаться от наследства

Согласитесь с тофутимом - в вашем текущем примере разумно двигаться и останавливаться на транспортном средстве.

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

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

Например, типы транспортных средств включают подводную лодку, лодку, самолет, автомобиль и велосипед. Вы можете разбить его на интерфейсы... IMoveable + Forward() + Backward() + Left() + Right()

IFloatable + Dock()

ISink() + BlowAir()

IFly() + взлет() + приземление()

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

Проблема в том, что вы можете в конечном итоге дублировать некоторый код в классе автомобиля/велосипеда для IMoveable.Left() и IMoveable.Right(). Вы можете превратить это во вспомогательный метод и агрегировать помощник... но если вы доведете его до логического завершения, вы все равно закончите рефакторингом многих вещей обратно в базовые классы.

Наследование и агрегация - это инструменты... ни один из них не является "злом".

Надеюсь, это поможет.

Наследование («расширение классов») накладывает существенные ограничения на дизайн классов, и я не уверен, что использование интерфейсов в качестве замены наследованию — лучшая идея, поскольку она не прошла DRY-тест.

В наши дни композиция предпочтительнее наследования, поэтому вы можете рассмотреть этот пост: Предпочесть композицию наследованию?

Интересный вопрос. У всех разные подходы. Но это все основано на личном опыте и выборе.

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

Это дает несколько преимуществ, основанных на опыте.
1. Во время вызовов функций вы можете передавать элементы как тип интерфейса или тип абстрактного класса.
2. Общие переменные, такие как ID, имена и т. д., могут быть помещены в абстрактный класс.
3. Простота обслуживания. Например, если вы хотите внедрить новый интерфейс, просто быстро внедрите его в абстрактном виде.

Если вы будете помнить о фундаментальной разнице между интерфейсами и классами, вам будет проще решить, какой из них использовать. Разница в том, что интерфейсы представляют собой просто протокол (обычно поведенческий) между задействованными объектами, а абстрактные классы представляют собой некие незавершенные конструкции, включающие в себя некоторые части (данные). В примере с автомобилем интерфейс — это, по сути, план для обычного автомобиля. А абстрактный класс будет подобен сборному кузову конкретной модели автомобиля, который необходимо заполнить оставшимися частями, чтобы получить конечный продукт. Интерфейсы даже не обязательно должны быть на Java — это ничего не изменит — все равно план.

Как правило, вы будете использовать абстрактный класс в своей конкретной структуре реализации, чтобы предоставить его потребителям некоторые базовые функции. Если вы просто заявляете, что никогда не используете абстрактный класс в пользу интерфейса - это просто неправильно с практической точки зрения. Что если вам нужно 10 реализаций одного и того же интерфейса с 90% одинаковым кодом. Копировать код 10 раз? Хорошо, может быть, вы использовали бы здесь абстрактный класс, но добавили бы интерфейс поверх него. Но зачем вам это делать, если вы никогда не собираетесь предлагать свою иерархию классов внешним потребителям? Я использую слово внешний в очень широком смысле - это может быть просто другой пакет в вашем проекте или удаленный потребитель.

В конечном счете, многие из этих вещей являются предпочтениями и личным опытом, но я не согласен с большинством общих утверждений, таких как extends is evil. Я также предпочитаю не использовать дополнительные классы (интерфейсы или абстрактные), если только это не требуется для определенных частей дизайна.

Просто мои два цента.

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

Решение об использовании наследования, композиции или интерфейсов сводится к нескольким простым принципам:

1. If one needs both code reuse and substitutability, and the restrictions imposed on polymorphism aren't too bad, use inheritance.
   
   
2. If one needs code reuse, but not substitutability, use composition.
   
   
3. If one needs substitutability, but not code reuse, or if the restrictions inheritance would impose upon polymorphism would be worse than duplicated code, use interfaces.
   
   
4. If one needs substitutability and code reuse, but the restrictions imposed by polymorphism would be unacceptable, use interfaces to wrap encapsulated objects.
   
   
5. If one needs substitutability and code reuse, and the restrictions imposed by polymorphism would not pose any immediate problem but might be problematic for future substitutable classes, derive a model base class which implements an interface, and have those classes that can derive from it do so. Avoid using variables and parameters of the class type, though--use the interface instead. If you do that, and there is a need for a substitutable class which cannot very well derive from the model base class, the new class can implement the interface without having to inherit from the base; if desired, it may implement the interface by wrapping an encapsulated instance of a derivative of the model type.

При принятии решения о том, могут ли будущие замещаемые классы иметь трудности с получением от базового класса, может потребоваться суждение. Я склонен думать, что подход № 5 часто предлагает лучшее из всех миров, когда требуется взаимозаменяемость. Часто это дешевле, чем использование только интерфейсов, и ненамного дороже, чем использование только наследования. Если есть потребность в будущих классах, которые можно заменять, но нельзя вывести из базы, может потребоваться преобразовать код для использования подхода № 5. Использование подхода № 5 с самого начала позволит избежать необходимости рефакторинга кода позже. (Конечно, если нет необходимости заменять класс, который не может быть производным от базового, дополнительные затраты, какими бы незначительными они ни были, могут оказаться ненужными).

Вам нужен ответ для вашего конкретного случая или вообще? В описанном вами случае нет ничего плохого в использовании абстрактного класса. Нет смысла использовать интерфейс, когда все клиенты должны реализовать один и тот же код для Move() и Stop().

• Не верьте всему, что вы читаете

  • Many times, inheritance is not bad, in fact, for data-hiding, it may be a good idea.

• По сути, используйте политику «только интерфейсы» только тогда, когда вы создаете очень маленькое дерево классов, в противном случае, я обещаю, это будет больно. Предположим, у вас есть «класс» Person (имеет eat() и sleep) и два подкласса, Mathematician (имеет doProblem() ) и Engineer ( buildSomething() ), затем переходите к интерфейсам. Если вам нужно что-то вроде класса Car, а затем 56 миллионов типов автомобилей, используйте наследование.

ИМХО.

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

Но если сравнивать интерфейс с абстрактным классом, то абстрактный класс всегда больше, чем интерфейс. Интерфейс — это всегда какой-то аспект класса, некая точка зрения, а не весь класс.

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