A-tit indd

330
Локатор служб (Service Locator) — 
Паттерны программирования игр
virtual void playSound(int soundID)
{
log("play sound");
wrapped_.playSound(soundID);
}
virtual void stopSound(int soundID)
{
log("stop sound");
wrapped_.stopSound(soundID);
}
virtual void stopAllSounds()
{
log("stop all sounds");
wrapped_.stopAllSounds();
}
private:
void log(const char* message)
{
// € 396…
}
Audio &wrapped_;
};
Как видите, она оборачивает другого поставщика 
аудио и предоставляет тот же интерфейс. Она не толь-
ко переадресует все вызовы внутреннему поставщику, 
но и фиксирует каждый вызов. Если программисту нуж-
но активировать журналирование аудиосистемы, он вы-
зывает данный метод:
void enableAudioLogging()
{
// 9 9 3.
Audio *service = new LoggedAudio(
Locator::getAudio());
// # 6 3.
Locator::provide(service);
}

---

Паттерны программирования игр
— Паттерны уменьшения связанности
331
Сейчас любые вызовы аудиосистемы, прежде чем вы-
полниться, фиксируются в журнале событий. И, конеч-
но, это прекрасно работает с нашей пустой службой, так 
что вы можете 
отключить
аудиосистему, но все равно 
записывать любые ее вызовы так, 
будто
она включена.
Архитектурные решения
Мы рассмотрели типичную реализацию, но есть пара 
вариантов использования данного паттерна.
Как происходит локация службы?
• Она регистрируется внешним кодом
Этот механизм используется в нашем примере, 
и он же — наиболее распространенная реализация 
из тех, что я встречал в играх.
• Это быстро и просто
. Функция 
getAudio()
про-
сто возвращает указатель. Он всегда будет встраи-
ваться компилятором, так что мы получим допол-
нительный уровень абстракции практически без 
потери производительности.
• Мы контролируем создание поставщика
. Рассмотрим 
службу для взаимодействия с игровыми контролле-
рами. У нас два конкретных поставщика: один для 
обычной игры и второй для сетевого режима. Онлайн-
поставщик передает ввод контроллера по сети, поэто-
му остальная часть игры думает, будто удаленные иг-
роки используют локальные контроллеры.
Чтобы все работало, конкретный онлайн-постав-
щик должен располагать информацией об IP-адресе 
удаленного игрока. Если бы локатор создавал объ-
ект самостоятельно, как бы он узнал, что туда пе-
редавать? Класс 
Locator
вообще не в курсе о се-
тевом режиме, не говоря уже об IP-адресе другого 
пользователя.
Регистрация поставщиков внешним кодом по-
зволяет избежать такой проблемы. Не локатор кон-
струирует класс, а сетевой код игры инстанциирует 

---