A-tit indd

Паттерны программирования игр
— Другой взгляд на паттерны проектирования
105
• Они не поддерживают параллельность.
Дни, ко-
гда игры запускались на простых одноядерных 
процессорах, давно прошли. Сегодня код должен 
по крайней мере 
работать
при многопоточности, 
даже если он не использует все преимущества па-
раллельной обработки. Если мы помещаем объ-
ект в глобальную область видимости, мы выделяем 
фрагмент памяти, способный видеть каждый поток 
и записывать туда данные, зная или не зная, что 
с ним делают другие потоки. Это приводит к вза-
имным блокировкам (deadlocks), ситуациям гонки 
(race conditions) и другим ошибкам в синхрониза-
ции, исправлять которые — настоящий ад.
Этих причин вполне достаточно, чтобы навсегда 
отпугнуть нас от объявления глобальных переменных, 
а следовательно, и от паттерна Одиночка (Singleton). 
Но как же нам 
стоит
проектировать игру? Как нам 
создать игру без использования глобального состоя-
ния?
На этот вопрос существует несколько внушитель-
ных ответов (даже книга в ваших руках — в некоторой 
степени 
есть
ответ на этот вопрос), но они не очевид-
ны, да и не так легко реализуемы. А нам тем временем 
все же надо написать игру. Паттерн Одиночка (Singleton) 
кажется панацеей. Он присутствует в книге о паттер-
нах проектирования в объектно-ориентированном 
программировании, следовательно, он 
должен
выгля-
деть очень солидно с точки зрения архитектуры, верно? 
К тому же он позволяет проектировать игры так, как это 
делали долгие годы.
К несчастью, он больше плацебо, чем лекарство. Если 
вы еще раз пробежитесь по списку проблем, вытекаю-
щих из использования глобальных переменных и эк-
земпляров, вы поймете: паттерн Одиночка (Singleton) 
не решает ни одну из их. А все потому, что одиночка 
и есть
глобальное состояние, просто инкапсулирован-
ное в класс.

---