Закон Деметры / одиночная ответственность, когда происходят события

Question

Я пытаюсь согласовать закон Деметры для сред программирования, в которых участвуют события - я пометил этот javascript и obj-c (NSNotificationCenter от Cocoa), потому что оба допускают события.

В такой среде выможет произвольно отделить любые два объекта, просто бросив их и привязав / подписавшись на события.В obj-c это может быть намного проще, чем просто передавать ссылку на объект, для которого нужно вызвать метод.Я думаю, что это, вероятно, не всегда полезно: с точки зрения производительности вы упускаете оптимизацию для отправки методов (вероятно, незначительную, если это не огромное приложение).Для удобства чтения программист может захотеть сделать явным, что один объект является зависимостью от другого, что неочевидно, когда объект просто выбрасывает события.

Мне хотелось бы кое-что подумать о роли событийв архитектуре программного обеспечения: как вы хотите сбалансировать привязку событий и прямой вызов метода?

Answer 1

Будьте осторожны с вашей терминологией. Слово «события» в контексте графического интерфейса пользователя часто означает события, сгенерированные пользователем, такие как щелчки мыши, нажатия, нажатия клавиш и т. Д., И события такого рода обычно не обрабатываются с использованием шаблона наблюдателя , который вы кажется, имеет в виду. В Cocoa и Cocoa-Touch пользовательские события обрабатываются с использованием схемы цепочки ответственности .

Оба паттерна способствуют слабой связи между объектами, но связь в наблюдателе, возможно, слабее. Объекты, которые участвуют в цепочке ответственности, обычно все наследуются от общего базового класса или иным образом соответствуют некоторому общему интерфейсу, и каждый объект в цепочке, как правило, знает о своих соседях в цепочке. При использовании обозревателя объект, отправляющий сообщение (например, уведомление в Какао), не знает, какие объекты могут получить сообщение, а объекты, получающие сообщение, обычно не знают, откуда оно пришло. В частности, в Cocoa и NSNotificationCenter нет даже общего интерфейса - каждый объект-наблюдатель регистрирует обработчик уведомлений, когда подписывается на получение уведомления.

Вы можете создать беспорядок с шаблоном наблюдателя, если будете злоупотреблять им. Отладка путаницы сообщений может быть очень сложной. Гораздо хуже, если сообщения доставляются наблюдателям синхронно (а они обычно это делают), объект, отправляющий сообщение, не может знать, насколько дорогой может быть отправка сообщения, а объекты, получающие сообщение, не имеют представления о том, как их собственная производительность может повлиять на остальную часть приложения. Тот факт, что количество наблюдателей для любого данного сообщения обычно не ограничено, позволяет легко случайно создать реальные проблемы с производительностью. Защитники закона Деметры могут щелкнуть языком и сказать: «Я же вам говорил», но это не значит, что вам следует избегать наблюдателей. При правильном использовании и понимании того, что наблюдатели не должны выполнять большую работу в ответ на сообщение, шаблон является мощным способом передачи информации в места, где он необходим, и он может упростить код, устраняя необходимость во многих отношения между объектами.