2015-09-11 3 views
1

Представьте, что у меня есть система объектов, которые являются излучателями событий, а также могут прослушивать события в других объектах. В этой системе эти объекты общаются между ними, главным образом, с помощью событий.OOP - Может ли и должны ли события быть частью абстракций?

Я хочу следить за хорошими объектно-ориентированными практиками, и я заинтересован в создании абстракций для своих объектов. Фактический язык, который я бы использовал, не имеет большого значения: эти абстракции могут быть интерфейсами или абстрактными классами, например.

Эти типы абстракций определяют методы и свойства объекта, но не определяют имена событий. Новые реализации могут принять решение о создании абсолютно новых событий ... Это правда, что вы используете всегда один и тот же метод для их броска, но если вы создаете новые имена событий, мое впечатление заключается в том, что вы нарушаете принцип открытого/закрытого: Я бы сказал, что это эквивалентно добавлению новых методов.

Был ли способ указать возможные события, которые может излучать такой объект, в абстракции, что этот объект следует?

Мне интересно, как это будет работать на таких языках, как Java, C++, Javascript и Typcript. Я не совсем уверен, поскольку я не знаю C#, но я думаю, что в этом языке события могут быть частью интерфейсов. Но меня интересует, как бы вы делали события частью абстракций на тех других языках, которые не поддерживают это простым способом.

ответ

1

Способность эффективно выполнять эти контракты в коде будет отличаться в зависимости от используемого языка, поэтому оптимальное решение не является языковым агностиком: существует идиоматический способ делать вещи на каждом языке.

Одно из решений, которое может быть реализовано, вероятно, на всех типизированных языках, - это сделать каждое событие эмитентом и полагаться на композицию.

Это в основном сводится к someObject.onSomeEvent.listen(handler) вместо someObject.listenTo('someEvent', handler).

Это подход, который они использовали в Google Dart, когда refactoring the DOM Events API. Поскольку события теперь являются членами класса, они могут легко стать частью кодового контракта.

Существуют, очевидно, другие способы, такие как создание конкретного класса событий для каждого события, а не использование строк. Преимущество этого решения заключается в том, что контракт не должен меняться при добавлении новых событий.

+0

thanks @plalx Мне понравился ваш ответ, и я не знал об этом событиях в Дарте. Я надеялся, что кто-то может добавить больше к разговору, но так как этого не произошло, я выбираю это как ответ –