Каков основной конкурирующий шаблон проектирования для конкретного наследования в архитектуре приложения?

Question

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

Answer 1

Я думаю, что вы придерживаетесь принципа дизайна:

"Фавор Композиция окончена Наследование ".

Answer 2

Очень популярной альтернативой наследования (как в подклассе) является составление и делегирование объектов.

Так что вместо

 public class B extends A implements I {
    // now I have all the methods from A
 }

вы делаете

public class B implements I {
     private I a;

     // delegate all methods
     public void methodOne(){
          a.methodOne();
     }
}

Композиция более гибкая, чем подклассы:

• Вы можете иметь более одного делегата (в отличие от только одного суперкласса, по крайней мере, в Java)
• Он четко отделяет интерфейс от реализации (тогда как с помощью суперкласса вы получаете и его методы, и их реализацию, и даже методы, которых нет в интерфейсе)
• Вы можете менять делегатов по конфигурации во время выполнения (тогда как экземпляр суперкласса компилируется). На этом основывается внедрение зависимостей.

Answer 3

наследование это не стиль

это инструмент

так же, как композиция

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

Винты с крестообразным шлицем лучше плоских головок.

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

разница между ними очевидна и проста - "is-a" против "has-a" - и хотя композицию можно использовать для имитации наследования (с lot дополнительной работы) обратное вообще не верно. Это не аргумент против наследования и не аргумент для композиции.

Семантика модели гораздо важнее, чем механизм, используемый для ее представления. Было бы глупо говорить, что «рептилия имеет животное и использует делегацию, чтобы раскрыть свои методы и свойства», а не «рептилия - это своего рода животное», не так ли? Так почему же делать то же самое с объектом без необходимости не так глупо?

наследование невероятно полезно и является фундаментальным для объектно-ориентированного программирования. Это не уйдет, пока не появится что-то лучшее, и я еще не опубликовал это; -)

[пусть огонь начнется!]

Answer 4

Если вы используете C ++, тогда вам следует серьезно рассмотреть возможность использования миксинов (примечание: некоторые другие языки утверждают, что поддерживают некоторые формы миксинов):

Wikipedia: http://en.wikipedia.org/wiki/Mixin
Dr. Dobbs: http://www.ddj.com/cpp/184404445.

Более интересным является «любопытно повторяющийся шаблон» (CRTP):

Wikipedia: http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern.

Я вижу CRTP как приложение миксинов, которое очень полезно.

Как только вы "получите это" (это займет некоторое время), вы поймете, что миксины очень веселые. Они дают вам метод повторного использования кода, который не сталкивается с проблемами повторного использования посредством наследования, но является более гибким и эффективным, чем использование композиции и делегирования.

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

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

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

Answer 5

Аллен Холуб описывает в этой статье , как реализация интерфейса предпочтительнее, чем создание подклассов. хотя это было написано в 2003 году, это все еще по теме. как ни странно, с 2009 года есть куча комментариев!

Answer 6

В Smalltalk & Perl есть также черты и роли. Они позволяют вам повторно использовать функциональность. Проверьте это статья .

Answer 7

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

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