Можно посмотреть на дело немного иначе.
Начать не с иерархии коробок, а с интерфейсов.
Тут видятся следующие 5 интерфейсов:
- Трехмерное
- Цветное
- Весящее
- Разрисованное
- Ящик

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

Дальше возникает вопрос уже о воплощении ящиков, как о носителях конкретной реализации различных комбинаций эти 1 обязательного + 4 опциональных интерфейсов (инт. "Ящик" плюс разные "перламутровые пуговицы").

Воплощение ящиков может быть сделано в виде некоторой иерархии. Плюс объекты-реализаторы опциональных интерфейсов, которые сами вне иерархии ящиков. Например (пардон, лень рисовать, я уж текстом):

== Вне иерархии ящиков - комплект имплементаторов опциональной функциональности:
[1] ПодержкаТрехмерного - держит габариты, вычисляет объем etc., и может управляться снаружи контроллером поддержки трехмерного (возможно также извещать его посланиями вроде "Трехмерность изменилась"). Может само предоставлять интерфейс Трехмерное.
[2] ПоддержкаЦветного - аналогично [1], но про Цветное. Может быть управляется снаружи контроллером поддержки цветного
[3] ПоддержкаВесящего - может управляться контроллером весящего
[4] ПоддержкаРазрисованного - может управляться контроллером разрисованного

(Этот комплект может быть применен не только к ящикам но и к шарам или иному)

== Иерархия ящиков - воплощает ящики, иногда привлекая имплементаторы разной функциональности:
(1) БазовыйЯщик - реализует интерфейс Ящик базовым образом
(2) ЯщикТрехмерный - потомок (1). Поддерживает функционал Трехмерного через композицию. Имеет в себе экземпляр класса [1], которому подсовывает себя в качестве контроллера трехмерности. Его же выдает наружу при запросе интерфейса, или делегирует ему вызовы.
(3) ЯщикЦветной - потомок (2). Поддерживает Цветное с помощью композиции, инстанциируя [2], и будучи контроллером Цветного
(4) ЯщикВесящий - потомок (2). Поддерживает Весящее через [3]
(5) ЯщикЦветнойВесящий - потомок (3). Поддерживает Весящее через [3]. А можно сделать и потомком (4), поддерживающим цветное через [2]. Или вовсе потомком (2), поддерживающим цветное через [2], а весящее через [3]. Выбор варианта зависит от того, насколько обширна реализация "контроллера Цветного", "контроллера Весщяего". Одно дело, когда, например, надо обрабатывать много специфичных событий от имплементатора. Много кода по реализации контроллера. А другое дело, когда имплементатор надо просто инстанциировать и выдавать/делегировать его при запросе интерфейса. Если есть разница, то выбрать тот вариант, который требует написать меньше кода в (5). Впоследствии родословную (5) можно будет менять не сильно беспокоя остальную иерархию.
(6) ЯщикЦветнойВесящийРазрисованный - потомок (5), поддерживает Разрисованное через [4]

softwarerMumbo[3] ПоддержкаВесящего - может управляться контроллером весящего
Mumbo, это всё как бы очевидно. Проблема в том, что когда весящими должны быть 10 разных классов, делать 10 реализаций как бы тупо, а делать 10 тупых переадресаций на одну реализацию немногим умнее. Наследование классов и implements - два метода, позволяющие обойтись без копирования, поэтому именно их хочется использовать в подобных случаях.
softwarer, оборот "это всё как бы очевидно" - это похоже на тупое фиглярство и понты. А это все никому не нужно, так что давайте лучше разберемся.

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

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

Аналогично и в рассмотренном примере. Переменные классов ПоддержкаЦветного и ПоддержкаВесящего - это аналоги переменной класса Строка, переменной класса Вектор. С тем небольшим отличием, что они могут поддерживать (если надо) еще и управление со стороны внешнего контроллера.

softwarerВаш пост, если убрать воду,
Ну какую еще воду? Зачем такие наезды? Razel задал вопрос, я ответил ему подробно. Вы что без наездов не можете что-ли обосновать свои возражения?

softwarerс для описания наборов характеристик следует использовать интерфейсы
да, конечно

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

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

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

softwarer А когда мы используем строку как приватный член класса только для того, чтобы реализовать в классе методы, допустим, isEmpty(), toInteger(), convertToUtf8(), getIterator() и прочие, взяв их из этой строки, это не очень нормально. Если мы делаем такое, копируя код в разные классы, это тупо. Хотя может быть, кому-то и привычно.


Такого никто не предлагал, это какие-то фантазии или иллюзии. Предлагалось сделать классы под задачу ПоддержкаЦветности, ПоддержкаВесомости и использовать эти классы по их прямому назначению. Не ставить их в зависимость от Ящиков, но Ящики оснастить ими.

softwarerможно не реализовывать в классе указанные методы, а сделать метод, возвращающий интерфейс к ним (то есть в Вашем примере - как раз-таки getName()). Это избавляет от тупых переадресаций и в целом скорее лучше, но усложняет код использования.

В своем исходном сообщении я указывал на возможность просто выдавать имплементатор при запросе интерфейса. А с другой стороны, при необходимости, вполне возможно использовать перевызовы, и не надо впадать в крайности фанатизма и обзывать их тупыми.

Хорошо известен принцип: Композиция предпочтительнее наследования реализации. Если можно свести задачу к композиции реализаций - то это следует делать.