A-tit indd

Паттерны программирования игр
— Другой взгляд на паттерны проектирования
115
Если позже в архитектуру игры разработчики 
внесут изменения, которые заставят 
Game
поддер-
живать несколько экземпляров (для разделения 
потоков или в тестовых целях), они не повлияют 
на 
Log
, 
FileSystem
или 
AudioPlayer
— не бу-
дет абсолютно никакой разницы. Но у названного 
метода есть и недостаток: код становится более за-
висимым от самого 
Game
. Если некий класс захочет 
просто воспроизвести звук, ему понадобится знать 
о 
World
, чтобы через него получить доступ к аудио-
проигрывателю.
Мы будем использовать гибридное реше-
ние. Код, знающий о 
Game
, будет получать доступ 
к 
AudioPlayer
через него. А не знающий — дру-
гими способами, описанными здесь.
• Получить через Локатор служб.
Ранее мы подра-
зумевали под понятием «глобальный класс» регу-
лярный конкретный класс наподобие 
Game
. Хотя 
можно объявить класс, единственная цель суще-
ствования которого будет заключаться в предо-
ставлении глобального доступа к объектам. Это 
паттерн, который называют Локатор служб (Service 
Locator), и ему посвящена целая глава.
 Что же остается паттерну Одиночка 
(Singleton)
Однако вопрос «где мы 
должны
использовать паттерн 
Одиночка (Singleton)» по-прежнему на повестке дня. 
Честно, я никогда не использовал его полностью таким, 
каким его описала «Банда четырех». Если мне нужно 
гарантировать единственность экземпляра, я исполь-
зую статический класс. Когда такой вариант не подхо-
дит, я просто использую статический флаг, чтобы уже 
во время выполнения удостовериться: экземпляр, созда-
ваемый классом, единственный.
В книге есть еще пара глав, касающихся той же про-
блемы. Паттерн Подкласс песочница (Subclass Sandbox) 

---

(с. 232) предоставляет общий доступ к экземплярам не-
кого класса, не делая их глобально доступными. Паттерн 
Локатор служб (Service Locator) (с. 321) не просто поме-
щает объекты в область глобальной видимости, но еще 
и предоставляет больше гибкости в настройке этих объ-
ектов.

---