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