A-tit indd

Паттерны программирования игр
— Паттерны уменьшения связанности
285
private:
InputComponent* input_;
PhysicsComponent physics_;
GraphicsComponent graphics_;
};
Сейчас, когда мы инстанцируем класс 
Bjorn
, мы мо-
жем передать ему компонент обработки пользователь-
ского ввода, чтобы тот его использовал, примерно так:
Bjorn* bjorn = new Bjorn(new 
PlayerInputComponent());
Этот экземпляр может быть любого конкретного 
типа, который реализует интерфейс 
InputComponent
. 
Но приходится платить производительностью: сейчас 
update()
является вызовом виртуального метода и за-
тормаживает процесс. Но что мы получаем взамен?
Большинство консолей требует от игры поддерж-
ки «деморежима». Если игрок сидит перед экраном 
главного меню и ничего не делает, то игра запускается 
и управление передается ей самой. Таким образом игра 
не выжжет главное меню на экране вашего монитора, 
да и будет выглядеть более привлекательно на стенде 
в магазине.
А помещение компонента ввода за интерфейс как раз 
позволяет нам это реализовать. У нас уже есть конкрет-
ный компонент 
PlayerInputComponent
, который ис-
пользуется в обычной ситуации, когда играет пользова-
тель. Создадим еще один:
class DemoInputComponent : public InputComponent
{
public:
virtual void update(Bjorn& bjorn)
{
// †† „6…
}
};

---

286
Компонент (Component) — 
Паттерны программирования игр
Когда игра переходит в режим демо, вместо того что-
бы конструировать Бьорна так жe, как и раньше, мы свя-
зываем его с новым компонентом:
Bjorn* bjorn = new Bjorn(new 
DemoInputComponent());
Таким образом, просто подменяя компоненты, мы 
получили полностью функциональный, контролиру-
емый компьютером режим демо. Мы также можем по-
вторно использовать весь код, ответственный за гра-
фику и физику, для них не будет совершенно никакой 
разницы. Возможно, я немного странный, но именно 
ради таких вещей я просыпаюсь по утрам.