Важным правилом для любого движка или структуры является то, что независимо от того, какое наследование или что вы на самом деле используете, оно должно быть полностью необязательным для объекта, который должен обрабатываться движком. Поэтому, хотя конкретные сущности, которые обрабатываются механизмом, могут использовать сложное наследование, для механизма он полностью прозрачен, поскольку они абстрагированы от интерфейсов.
Например, вы определяете интерфейс IMovable. Двигатель может справиться с этим и перемещаться вокруг таких объектов. Затем вы можете предоставить реализацию по умолчанию, скажем, MovableBase, которая может, но не должна использоваться другими объектами, через наследование или композицию.
Обратите также внимание, что состав, как правило, считается лучше и чище, чем наследство. Чрезмерное использование наследования чрезвычайно часто приводит к нарушению принципа замены Лискова , который является одним из принципов 5 SOLID . Вы можете найти множество статей о наследовании и составе в Google .
Наследование в обычном использовании на самом деле имеет тенденцию нарушать многие принципы ООП и вносить большую зависимость. Это часто рассматривается как фундаментальная концепция в ООП, но вам лучше, если вы задумываетесь об этом как об одном из многих способов добиться повторного использования кода.
Поэтому, вместо того, чтобы сильно беспокоиться о том, как вы будете создавать конкретные компоненты, сначала вам нужно абстрагировать их, чтобы можно было применить принцип инверсии зависимостей . Таким образом, вы получите архитектуру с чрезвычайно плохой связью. Если сущность оказывается излишне сложной или если вы обнаружите, что вы можете извлечь некоторый код для повторного использования или вам необходимо изменить механизм наследования, другой код не затрагивается.
Вы можете обнаружить, что на самом деле попытка разделить ваши сущности на несколько уровней наследования имеет мало смысла, потому что вещи становятся излишне многословными и странно переплетающимися. Однако, абстрагирование различных «аспектов» или «ролей» ваших сущностей, таких как IMovable, IBounceable, IExplodable и т. Д., Окажется полезным. Любая сущность может выбрать реализацию любого интерфейса по желанию и, таким образом, будет обработана соответствующим образом движком.
Наиболее важным шагом в разработке программного обеспечения является разработка архитектуры, в которой различные модули радикально разделены и взаимодействуют через узкие интерфейсы. Когда модуль становится большим, затем примените тот же шаг к нему и выполните рефакторинг его для подмодулей (вы можете сделать это, не беспокоясь об остальной части программного обеспечения, просто потому, что модуль хорошо инкапсулирован). Не пытайтесь разбить целое на части, если это не кажется естественным. Вы получите больше кода, который будет менее гибким.
Greetz
back2dos