Помогите найти: 10 причин что вы пишите не ООП-код

[lowka]

Сообщение от Psycho Tiger

Player extends Airship extends RotativeObject extends FlyingObject extends Sprite3D
5. Теперь объясните мне, что в этом плохого. В игре есть другие Airship`s, которые не игрок, есть вращающиеся объекты, а есть просто статичные летающие, и все экстендится от Sprite3D. Что плохого? Или речь исключительно о наследовании ради наследования?

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

[Psycho Tiger]

Сообщение от lowka

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

Ошибка проектирование налицо, если какому-то классу нужен весь функционал другого класса и это "оказывается".

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

[lowka]

Сообщение от Psycho Tiger

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

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