Таким образом, разработка игр с использованием объектно-ориентированной парадигмы в C ++ обычно включает идею GameObjects и их компонентов.Прежде всего, GameObject должен представлять собой список компонентов, как показано ниже:
class GameObject {
list<Component*> m_components;
Component* getComponent(component){}
}
Теперь, конечно, есть много других способов реализовать игровой объект лучше и эффективнее, но этоне имеет значения, потому что мое внимание будет сосредоточено на компонентах.То, как игровые объекты состоят из компонентов, является классическим примером композиции через архитектуру, основанную на компонентах, поскольку каждый компонент представляет поведение для GameObject.
Сами компоненты могут состоять из нескольких «функций» или поведения, которые могут бытьнеобходимо.Например, у нас может быть компонент, который зависит от множества других классов с поведением, таких как clickables, drag and drop и другие классы.Принимая во внимание, что каждый подкомпонент имеет все необходимое для работы, они не зависят от вызова конструктора родительского класса, и что конкретные классы реализуют виртуальный метод из одного из родительских классов для выполнения действий в результате поведенияпроисходит.Я считаю, что использование виртуального наследования в этом случае кажется лучшим решением, чем использование другого уровня композиции.В итоге я получу следующее:
class Component {}
class clickable : virtual Component {
virtual onClick();
}
class draggable : virtual Component {
virtual onDrop();
}
Каждый класс делает то, что ему нужно, не вмешиваясь в базовый класс.Каждый добавил бы функциональность, которая может быть унаследована.все конкретные классы, которые нужно сделать, это переопределить предоставленный виртуальный.Это не могут быть просто интерфейсы, потому что каждый класс должен делать свое дело.Конкретный класс будет выглядеть следующим образом: class ConcreteComponent: public Component, public Clickable, public Dragable {}
Проблемы, требующие решения:
1 - static_casting отключен, поэтому я буду полагатьсяна dynamic_cast, и из-за их дорогостоящего характера, я буду вынужден вызывать их только во время создания экземпляра компонента и добавлять указатели в качестве переменных-членов, если требуются какие-либо кросс-поведенческие вещи.Я действительно ограничен этим?Будет ли прямое присоединение к базовому компоненту хотя бы смягчить часть проблемы, разрешая статическое приведение к любому конкретному объекту, даже если у них есть родительские классы, которые являются виртуальными базовыми классами?
2 - С точки зрения скорости, насколько хуже будет опора на виртуальные классы, чем реализация прямого наследования.
3 - существует ли реальная реализация на основе жизнеспособной композиции для решения такого рода проблемвместо?не является ли сильная зависимость от композиции плохим запахом кода, особенно когда он используется на разных уровнях?