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

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

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

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

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

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

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

Объект Range имеет свойства width и height, которые измеряются в точках.

Просто добавьте заголовок к кнопке .

 < button title = «Hello World!» > Образец кнопки  

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

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

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

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» в делегате по-прежнему будет ссылаться на экземпляр B. Это означает, что this.getName () запускает отправку метода из класса B. Мы достигаем того же, что и при наследовании. Это механизм, используемый в языке на основе прототипа , таком как 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() ; ... }
}

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

Обсуждение

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

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

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

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

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

• Делегирование является наследованием

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

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

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

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

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