A-tit indd

65
примере этой главы. Одновременно просматривается 
список наблюдателей и всем им отправляется уведом-
ление.
Рис. 4.2
. Субъект и список его наблюдателей
Довольно просто, не так ли? Всего один класс, содер-
жащий список указателей на экземпляры некоторого 
интерфейса. Трудно поверить, неужели что-то настоль-
ко простое является коммуникативной основой бесчис-
ленных программ и фреймворков.
Но паттерн Наблюдатель (Observer) подвергается 
и критике. Когда я спросил других разработчиков игр их 
мнение, они высказали множество претензий. Давайте 
посмотрим, удастся ли нам решить перечисленные про-
блемы.
«Слишком медленный»
Я слышу это часто, в основном от программистов, кото-
рые на самом деле не знают тонкостей паттерна. У них 
есть предположение по умолчанию, будто все, что пах-
нет «паттерном проектирования», должно включать 
в себя груды классов и косвенности и другие необыкно-
венные способы разбазаривания ресурсов ЦП.
Паттерн Наблюдатель (Observer) имеет такую плохую 
репутацию, поскольку вокруг него витает множество ту-
манных понятий: «события», «сообщения» и даже «при-
вязка данных». Некоторые из этих систем 
могут
быть 
медленными (часто преднамеренно и по веской причи-
не). Они включают такие вещи, как очередь или дина-
мическое выделение памяти для каждого уведомления.
В реальном коде я избе-
гал бы использования 
наследования. Вместо 
этого я сделал бы так, 
чтобы 
Physics
содер-
жал
экземпляр 
Subject
. Вместо того 
чтобы наблюдать за са-
мим физическим движ-
ком, субъектом будет от-
дельный объект 
«событие падения». На-
блюдатели могли бы за-
регистрировать его, ис-
пользуя что-то вроде:
physics.
entityFell().
addObserver(this);
Для меня в этом за-
ключается разница ме-
жду системами «наблю-
датель» и «события». 
В первом случае вы на-
блюдаете 
нечто, сделав-
шее что-то интересное
. 
Во втором вы наблю-
даете объект, который 
представляет собой 
то интересное, что 
было сделано
.

---