A-tit indd

Паттерны программирования игр
— Другой взгляд на паттерны проектирования
61
Код просто говорит: «Э-э, я не знаю, заботит ли это 
кого-нибудь, но вон та штука упала. Поступай с полу-
ченной информацией как хочешь».
Система достижений работает так, что всякий раз, 
когда код, ответственный за физику, отправляет уве-
домление, она получает его. Затем система может про-
верить, является ли падающее тело нашим недограци-
озным героем, случалось ли подобное ранее и было ли 
место, где он столкнулся с неприятной механикой игры, 
действительно мостом. Если все совпало, то система до-
стижений с фейерверками и фанфарами разблокирует 
соответствующий значок — и все это без вмешательства 
в код физического движка.
Фактически мы можем изменить набор достижений 
или полностью удалить всю систему достижений, не ка-
саясь и строки в коде физического движка. Он будет про-
сто продолжать отправлять свои уведомления, не обра-
щая внимания на то, что они больше никому не нужны.
Как это работает
Если вы не знали, как реализовать данный паттерн, то, 
глядя на описание выше, уже наверняка догадались. Од-
нако для полной уверенности я все же пробегусь по это-
му процессу.
Наблюдатель
Мы начнем с того любопытного класса, который хочет 
знать, когда какой-то другой объект делает что-то инте-
ресное. Эти любознательные объекты определяются вот 
таким интерфейсом:
class Observer
{
public:
virtual ~Observer() {}
virtual void onNotify(const Entity& entity,
Event event) = 0;
};
Физический движок 
должен решить, какие 
уведомления отправ-
лять, поэтому нельзя 
сказать, что он абсо-
лютно лишен связанно-
сти с другим кодом. 
Но, проектируя архитек-
туры программ, чаще 
всего мы пытаемся улуч-
шить код, а не сделать его 
совершенным.
Конечно, если мы 
бес-
следно
удалим систему 
достижений и ничто 
другое не будет ждать 
уведомлений от физи-
ческого движка, мы смо-
жем удалить и код са-
мого уведомления. 
Но на этапе разработки 
все же приятно иметь 
такую гибкость.

---