A-tit indd

Какова область службы?
До этого момента мы предполагали, что локатор пре-
доставляет доступ к службе 
любому
, кто его запросит. 
И хотя таков типичный способ использования данного 
паттерна, можно ограничить доступ до единого класса 
и его наследников вот так:
class Base
{
// @ 3
// service_…
protected:
// 6 3
static Audio& getAudio() {return *service_;}
Облегчить эту задачу 
можно путем добавле-
ния в пустую службу 
функции вывода некото-
рой отладочной инфор-
мации.

---

338
Локатор служб (Service Locator) — 
Паттерны программирования игр
private:
static Audio* service_;
};
Таким образом доступ к службе ограничен только 
классами, которые наследуют от класса 
Base
. Преиму-
щества есть у обоих вариантов.
• Если доступ глобальный
• Это позволяет использовать службу из любой ча-
сти кода
. Большая часть служб должна существо-
вать в едином экземпляре. Позволяя всему коду 
иметь доступ к службе, мы избежим ситуаций, ко-
гда некоторые части будут инстанциировать соб-
ственных поставщиков из-за того, что не могут по-
лучить доступ к «настоящей».
• Мы теряем контроль над тем, где и когда служ-
ба используется
. Мы платим эту цену, когда делаем 
что-то глобально доступным. Кто угодно может по-
лучить доступ. В главе «Одиночка (Singleton)» (с. 97) 
собраны все монстры фильма ужасов, которых со-
здает глобальная область видимости.
• Если доступ ограничен одним классом
• Мы контролируем связанность
. Это главное пре-
имущество. Ограничивая доступ к службе одним 
деревом наследования, мы можем гарантировать, 
что системы, которые должны оставаться не связан-
ными, остаются не связанными.
• Это может привести к дублированию
. Потенциаль-
ный недостаток в том, что, если паре независимых 
классов 
нужен
доступ к службе, каждому из них при-
дется иметь собственную ссылку на нее. Какие бы 
процессы ни использовались для поиска службы, их 
придется дублировать для каждого из классов.
(Другой способ — изменить архитектуру иерархии 
классов так, чтобы у них был общий базовый класс. 
Но это скорее создаст больше проблем, чем решит.)

---

Общая рекомендация: если служба используется 
только в одной области игры, то лучше ограничить об-
ласть видимости одним классом. Например, служба 
для доступа в сеть может быть предоставлена только 
онлайн-классам. А службы, которые используются бо-
лее широко, например журналирование, должны быть 
глобально доступными.
Смотрите также
• Паттерн Локатор служб (Service Locator) во многом 
близок паттерну Одиночка (Singleton) (с. 97), поэто-
му имеет смысл рассматривать их вместе, чтобы ре-
шить, какой лучше подходит в той или иной ситуа-
ции.
• Unity фреймворк использует этот паттерн совмест-
но с паттерном Компонент (Component) (с. 272) 
во встроенном методе 
GetComponent()
.
• Во фреймворке XNA от Microsoft для разработки игр 
этот паттерн встроен в базовый класс 
Game
. Каждая 
сущность игры обладает объектом 
GameServices
, 
который можно использовать для поиска и реги-
страции различных видов служб.

---