Каковы симптомы в кодовой базе, которые указывают на то, что требуется подход прослушивания событий?
Мне кажется, что когда есть классы, которые должны быть вызваны множеством, а не определены во множестве других классов во время разработки, вам нужна какая-то сигнальная структура, но я хотел бы услышать, какие существуют другие ситуации, которые могут быть улучшена путем изменения модели на основе событий.
Ответы:
Подход Event / Listener пытается избежать тесной связи , поэтому все запахи кода, которые указывают на это, будут указывать на подход.
Исходя из этого, я бы предложил следующие симптомы:
большие конструкторы , так как каждый объект должен знать каждый другой объект и не может функционировать без него. Может быть, замаскировано так много obj.set_dependecy(x)сразу после вызова конструктора.
двунаправленные зависимости , потому что без событий на императивном языке поток информации в основном «проталкивается» (вызывая метод someones)
«иерархию знаний» определить сложно . Это двунаправленные зависимости , просто еще один фокус: если есть A, который слушает B, A знает о B, но B не знает об A, так что есть «иерархия»: некоторые объекты ничего не знают, другие знают другие и т. д. Например, при реализации MVC, например: http://en.wikipedia.org/wiki/Model_View_Controller , модель знает только себя, представление знает модель, а контроллер знает представление и модель.
Когда вы не можете или не должны знать, что должно реагировать на набор сообщений / сигналов / событий.
Часто это когда вы хотите, чтобы «мир» знал о чем-то, что происходит в модуле (классе или системе классов), но вы не хотите беспокоиться о том, что называется.
В частности, связанный запах кода - это когда вы чувствуете, что начинаете смешивать код из независимых модулей, один из которых выполняет то, на что другой должен реагировать. Как только вы увидите, что вам необходимо вызвать код из модуля B в зависимости от состояния / событий модуля A, вам понадобятся прослушиватели событий.
Я бы изменил ваш вопрос и сказал бы: когда основанное на событии не является правильным решением для объектно-ориентированного приложения? Я думаю, что большинство ОО-приложений могут выиграть, если они предназначены как производители событий и потребители.
В конце концов, «вызов метода» на самом деле является сообщением, поступающим к объекту, и объект отвечает за решение, будет ли он что-то делать с сообщением, и выполнение операции. Это не очень понятно в строго типизированных языках, таких как Java, но становится более очевидным в динамических языках, таких как Ruby.
Другой интересный момент разработки приложения на основе событий состоит в том, что обычно внутренние компоненты должны быть должным образом изолированы и согласованы, в противном случае код становится очень и очень быстрым. В качестве примера, мне действительно нравится концепция шестиугольной архитектуры, используемая Алистером Кокберном, так как обычно этот шаблон создает лучшую инкапсуляцию и заставляет (на мой взгляд) создавать более сплоченные компоненты.
Я думаю (но я, вероятно, ошибаюсь), что это также связано с концепцией доменных событий , управляемой доменом , в которой классы домена испускают события, которые захватываются другими объектами, а эти объекты испускают еще другие события (вы видите, где это происходит: D). Что мне нравится в этом шаблоне, так это то, что интерфейсы должны моделировать роли, а не реализации.
Извините, если у меня нет особого смысла, я экспериментировал с этими шаблонами в течение последних нескольких месяцев с потрясающими результатами, но я все еще пытаюсь понять концепции и то, как далеко они достигают.
Подумайте о том, что вам нужно было бы сделать, если бы прослушивателей событий (ака. Шаблон наблюдателя) не существовало.
Если у вас есть объект, у которого есть ссылки на список других объектов и который вызывает метод в определенный момент процесса, вам определенно должно было быть событие там.
Если у вас есть флаг на объекте, чтобы сказать, что что-то сделано, и вы наблюдаете этот флаг от других объектов, вам определенно следовало использовать модель, управляемую событиями.
Однако не путайте это с обратным вызовом. Если вы вызываете метод для другого объекта и передаете ему метод в исходном объекте для обратного вызова в данный момент, вы должны оставить его таким, а не использовать прослушиватель событий.