Помимо ромбовидного узора множественное наследование приводит к усложнению понимания объектной модели, что, в свою очередь, увеличивает затраты на обслуживание.
Композиция по своей сути проста для понимания, понимания и объяснения. Написание кода для него может быть утомительным, но хорошая IDE (прошло несколько лет с тех пор, как я работал с Visual Studio, но, безусловно, во всех IDE Java есть отличные инструменты автоматизации сочетаний клавиш), вы должны преодолеть это препятствие.
Кроме того, с точки зрения обслуживания, «проблема с бриллиантами» возникает и в случаях не буквального наследования. Например, если у вас есть A и B, и ваш класс C расширяет их оба, а у A есть метод 'makeJuice', который делает апельсиновый сок, а вы расширяете его, чтобы сделать апельсиновый сок с оттенком лайма: что происходит, когда дизайнер для ' B 'добавляет метод' makeJuice ', который генерирует электрический ток? «А» и «В» могут быть совместимыми «родителями» прямо сейчас , но это не значит, что они всегда будут такими!
В целом, принцип стремления избежать наследования, особенно множественного наследования, является обоснованным. Как и во всех принципах, есть исключения, но вы должны убедиться, что мигающий зеленый неоновый знак указывает на любые кодируемые вами исключения (и тренируйте свой мозг так, чтобы каждый раз, когда вы видите такие деревья наследования, вы рисовали в своем собственном мигающем зеленом неоне знак), и что вы проверяете, чтобы убедиться, что все это имеет смысл время от времени.