A-tit indd

72
Наблюдатель (Observer) — 
Паттерны программирования игр
Мы снова вернулись к тому, что можем наблюдать не-
сколько субъектов одновременно.
Рис. 4.4.
Объект и связанный список узлов, указывающих 
на наблюдателей
А способ, помогающий избежать динамического вы-
деления памяти, прост: поскольку все узлы имеют оди-
наковый размер и тип, вы предварительно выделяете 
пул объектов (с. 388) для них. Это дает вам набор фикси-
рованного размера из узлов, так что вы можете работать 
с ними: многократно использовать без фактической не-
обходимости распределять память.
Оставшиеся проблемы
Думаю, мы изгнали трех монстров, которые отпугива-
ли людей от этого паттерна. Нам удалось показать, что 
он прост, быстр и может аккуратно работать с памятью. 
Но обязательно ли теперь постоянно использовать на-
блюдателей?
Это совсем другой вопрос. Подобно любому паттер-
ну проектирования, паттерн Наблюдатель (Observer)
не панацея. Даже при правильном и эффективном вне-
дрении он может оказаться неправильным решением. 
Причина, по которой хорошие паттерны приобретают 
плохую репутацию, проста: люди применяют хорошие 
паттерны к решению не тех задач и в итоге делают все 
еще хуже.
Остаются две проблемы: одна техническая и одна, 
больше относящаяся к сложностям поддержки. Сначала 
Связанные списки бы-
вают двух видов. Пер-
вый, который вы изу-
чили еще в школе, 
включает в себя объект-
узел, содержащий дан-
ные. В предыдущем при-
мере со связанными 
наблюдателями это 
представлено следую-
щим образом: 
данные
(в нашем случае наблю-
датель) содержали 
узел
(то есть указатель 
next _
).
Второй вид называ-
ется «интрузивным» 
связанным списком, по-
тому что использование 
объекта в списке пред-
полагает внедрение 
в определение самого 
объекта. Это делает ин-
трузивные списки ме-
нее гибкими, но, как мы 
видели, более эффек-
тивными. Они по-
пулярны в местах типа 
ядра Linux, где имеет 
смысл идти на подоб-
ный компромисс.

---