Есть ли что-нибудь, что композиция не может выполнить это наследование?

Ответ 1

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

Преобразование наследования в делецию

Скажем, у нас есть следующие классы, реализованные с наследованием:

public class A {
    String a = "A";
    void doSomething() { .... }
    void getDisplayName() {  return a }
    void printName { System.out.println( this.getDisplayName() };   
}

public class B extends A {
    String b = "B";
    void getDisplayName() {  return a + " " + b; }
    void doSomething() { super.doSomething() ; ... }    
}

Материал работает красиво, а вызов printName в экземпляре B будет печатать "A B" в консоли.

Теперь, если мы перепишем это с делегированием, получим:

public class A {
    String a = "A";
    void doSomething() { .... }
    void getDisplayName() {  return a }
    void printName { System.out.println( this.getName() };  
}

public class B  {
    String b = "B";
    A delegate = new A();
    void getDisplayName() {  return delegate.a + " " + b; }
    void doSomething() { delegate.doSomething() ; ... } 
    void printName() { delegate.printName() ; ... }
}

Нам нужно определить printName в B, а также создать делегат при создании экземпляра B. Вызов doSomething будет работать так же, как и с наследованием. Но вызов printName будет печатать "A" в консоли. Действительно, с делегацией мы потеряли мощную концепцию "this", связанную с экземпляром объекта и базовыми методами, способными вызывать методы, которые были отменены.

Это можно решить на языке, поддерживающем чистое делегирование. При чистое делегирование "this" в делегате по-прежнему будет ссылаться на экземпляр B. Это означает, что this.getName() начнет отправку метода из класса B. Мы достигнем того же, что и с наследованием. Это механизм, используемый в prototype-based, например Self, у которых есть делегирование, имеет встроенную функцию (вы можете прочитать здесь, как наследование работает в Self).

Но Java не имеет чистого делегирования. Когда они застряли? Нет, мы все еще можем сделать это с еще большим усилием:

public class A implements AInterface {
    String a = "A";
    AInterface owner; // replace "this"
    A ( AInterface o ) { owner = o }
    void doSomething() { .... }
    void getDisplayName() {  return a }
    void printName { System.out.println( owner.getName() }; 
}

public class B  implements AInterface {
    String b = "B";
    A delegate = new A( this );
    void getDisplayName() {  return delegate.a + " " + b; }
    void doSomething() { delegate.doSomething() ; ... } 
    void printName() { delegate.printName() ; ... }
}

Мы в основном реинжинируем то, что обеспечивает встроенное наследование. Имеет ли это смысл? Нет. Но это иллюстрирует, что наследование всегда может быть преобразовано в делецию.

Обсуждение

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

Есть некоторые известные подводные камни о наследовании и хрупкости, которые он может внести в дизайн. Особенно, если иерархия классов развивается. Также могут возникнуть проблемы с equality в hashCode и equals, если используется наследование. Но с другой стороны, это еще очень элегантный способ решения некоторых проблем.

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

(Моя теория заключается в том, что, когда кто-то начинает делать OO, у нас возникает соблазн чрезмерно использовать наследование, потому что оно воспринимается как особенность языка. Затем мы изучаем делегирование, которое является шаблоном/подходом, и мы также учимся любить его. Через некоторое время мы находим баланс между обоими и развиваем чувство интуиции, из которого лучше в этом случае. Ну, как вы можете видеть, мне все еще нравятся оба, и оба заслуживают некоторой осторожности перед тем, как их ввести.)

Некоторая литература

• Делегирование - это наследование

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

• По понятию наследования

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

• Систематически рефакторинг наследования для делегирования в java

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

Ответ 2

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

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

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

Ответ 3

Рассмотрим набор инструментов gui.

Элемент управления редактированием - это окно, оно должно наследовать функции закрытия окна window/enable/paint - оно не содержит окна.

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

Ответ 4

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

Предположим, что у меня есть библиотека Widget с закрытым исходным кодом, которую я использую в проекте (это означает, что детали реализации являются для меня загадкой, кроме того, что документировано). Теперь предположим, что у каждого виджета есть возможность добавлять дочерние виджеты. С наследованием я мог бы расширить класс Widget для создания CustomWidget, а затем добавить CustomWidget как дочерний виджет любого другого виджета в библиотеке. Тогда мой код для добавления CustomWidget будет выглядеть примерно так:

Widget baseWidget = new Widget();
CustomWidget customWidget = new CustomWidget();
baseWidget.addChildWidget(customWidget);

Очень чистая и поддерживает правила библиотеки для добавления дочерних виджетов. Однако с составом это должно быть примерно так:

Widget baseWidget = new Widget();
CustomWidget customWidget = new CustomWidget();
customWidget.addAsChildToWidget(baseWidget);

Не так чисто, а также нарушает соглашения библиотеки

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

Ответ 5

Да. Это идентификация типа времени выполнения (RTTI).