A-tit indd

• Если компоненты предоставляются внешним кодом
• Объект становится более гибким.
Мы можем пол-
ностью изменить поведение объекта, передавая 
ему различные компоненты. В максимальной сте-
пени наш объект превращается в обобщенный кон-
тейнер компонентов, который мы можем исполь-
зовать в абсолютно различных целях снова и снова.
• Объект может быть отвязан от конкретных ти-
пов компонентов
. Если мы позволяем внешнему 
коду передавать компоненты, вполне вероятно, что 
мы позволим передавать и 
производные
типы ком-
понентов. В этом случае объект имеет информацию 
только об 
интерфейсе
компонента, а не о его кон-
кретном типе. И в результате может выйти непло-
хая архитектура с инкапсуляцией.
 Как компоненты взаимодействуют друг с другом?
В идеале мы стремимся к полному отсутствию связан-
ности, полностью изолированным друг от друга компо-
нентам. Но в жизни все работает иначе. Компоненты 
являются частью 
одного
объекта, частью одного целого, 
а значит, должны взаимодействовать. То есть общаться.
Как же компоненты могут общаться друг с другом? 
Есть несколько вариантов, но, в отличие от других 

---

290
Компонент (Component) — 
Паттерны программирования игр
«решений» этой книги, они не взаимоисключающие, 
то есть вы будете использовать несколько из них одно-
временно.
• Изменяя состояние объекта контейнера
• Контейнеры остаются не связанными
. Когда наш 
компонент 
InputComponent
устанавливает ско-
рость Бьйорна, а затем ее использует другой компо-
нент 
PhysicsComponent
, ни один из компонентов 
не подозревает о существовании другого. Они зна-
ют только, что скорость Бьйорна может изменяться 
с помощью неизвестной им черной магии.
• Любую информацию, которую используют ком-
поненты, необходимо помещать в сам объект-
контейнер
. Часто состояние требуется только огра-
ниченному числу компонентов из набора, не всем. 
Например, компоненты, ответственные за ани-
мацию и рендеринг, могут делиться графической 
информацией. Помещение такой информации 
в объект-контейнер, где она доступна 
каждому
компоненту, засоряет класс объекта.
Намного хуже, если мы используем один и тот же 
класс объекта с различной конфигурацией компо-
нентов. Это может привести к тому, что в памяти 
будет состояние, не нужное 
ни одному
из компонен-
тов. Если мы поместим информацию, необходимую 
для рендеринга, в объект-контейнер, то все неви-
димые объекты будут напрасно расходовать память.
• Коммуникация не выражена явно и зависит от по-
рядка обработки компонентов
. В нашем первона-
чальном примере кода порядок операций в методе 
update()
был тщательно продуман. Пользователь-
ский ввод изменял скорость, которая использова-
лась отвечающим за физику кодом для изменения 
позиции, а затем наступала очередь функции рен-
деринга, отображающего Бьйорна в нужном месте. 
Когда мы разбили код на компоненты, мы ставили 
задачу сохранить этот порядок.

---