A-tit indd

Паттерны программирования игр
— Паттерны оптимизации
365
на какой-то базовый класс или тип интерфейса. Вы 
получите весь возможный полиморфизм, а объекты 
будут абсолютно любого размера.
• Это гибко
. Код, который работает с коллекцией 
объектов любого типа, пока он поддерживает нуж-
ный интерфейс. Полная свобода.
• Это не так удобно в плане использования кэша
. Ко-
нечно, причина, почему мы вообще обсуждаем дру-
гие варианты, — неудобная для кэша косвенность 
из-за указателей. Но помните: если код не чувстви-
телен к производительности, то такое решение аб-
солютно нормально.
 Как определяются игровые сущности?
Если вы используете этот паттерн совместно с паттер-
ном Компонент (Component) (с. 272), то вы получите 
прекрасные непрерывные массивы для всех компонен-
тов, составляющих ваши игровые сущности. Игровой 
цикл будет проходить по ним напрямую, где роль самих 
объектов не столь важна, но может быть полезна в дру-
гих частях кода, где вам необходимо работать с единой 
концепцией «сущности».
Вопрос в том, как сущность должна быть представле-
на? Как следить за своими компонентами?
• Если игровые сущности — классы с указателями 
на компоненты
Так было в нашем первом примере традиционного 
объектно-ориентированного решения. Есть класс для 
GameEntity
, а у него — указатели на компоненты, 
которыми он обладает. Это просто указатели, а зна-
чит, нам остается только догадываться, где и в каком 
порядке расположены компоненты в памяти.
• Вы можете хранить компоненты в однородном 
массиве
. Поскольку сущности все равно, где в па-
мяти находятся компоненты, вы можете их ском-
поновать удобным вам образом, чтобы обрабаты-
вать в цикле.

---