Фатальная ошибка дизайна в моём коменте выше - в каком-то public API сделать агрегацию квадратом фигуры думаю будет вполне фатально. Ошибаешься. Во-первых, обычно квадрат является фигурой и правило нельзя применить. Во-вторых, я как-то раз заменил наследование агрегацией именно в этом случае, когда форма была всего лишь поведением. Ничего страшного не случилось, наоборот, квадрат стало легче юнит-тестировать отдельно от фигуры.
Менее фатальные ошибки - вместо наследующих друг-друга интерфейсов будут появлятся агрегирующие друг-друга классы с setter\getter-ами. Обычно у полей для делегирования/полиморфизма вообще нет публичных аксесоров, только инициализация в конструкторе.
Не надо "давить авторитетом". Покажи мне в этих источниках цитату в которой сказано что агрегацию надо использовать вместо наследования везде где только можно? Ты первый начал. Я изначально ссылался только на своё мнение, а потом на конкретные книги. Java Design: Objects, UML, and Process. Ссылается на GoF. Fine-tuning Abstraction @ Java boutique.
Собственно GoF, страница 34:"Как решать задачи проектирования" — "Наследование и композиция": "Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса. [...] С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование [Lie86, JZ91]."
no subject
Ошибаешься. Во-первых, обычно квадрат является фигурой и правило нельзя применить. Во-вторых, я как-то раз заменил наследование агрегацией именно в этом случае, когда форма была всего лишь поведением. Ничего страшного не случилось, наоборот, квадрат стало легче юнит-тестировать отдельно от фигуры.
Менее фатальные ошибки - вместо наследующих друг-друга интерфейсов будут появлятся агрегирующие друг-друга классы с setter\getter-ами.
Обычно у полей для делегирования/полиморфизма вообще нет публичных аксесоров, только инициализация в конструкторе.
Не надо "давить авторитетом". Покажи мне в этих источниках цитату в которой сказано что агрегацию надо использовать вместо наследования везде где только можно?
Ты первый начал. Я изначально ссылался только на своё мнение, а потом на конкретные книги.
Java Design: Objects, UML, and Process. Ссылается на GoF.
Fine-tuning Abstraction @ Java boutique.
Собственно GoF, страница 34:"Как решать задачи проектирования" — "Наследование и композиция": "Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса. [...] С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование [Lie86, JZ91]."