On 20 July 2013 12:48, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
2013/7/19 Igor Stasenko <siguctua@gmail.com>
So, on your place, if you really need a lot of classes with announcer capabilities, you can do it like that:
Object subclass: #ObjectWithAnnouncer instvars: 'announcer'
ObjectWithAnnouncer is exactly what I think about Announcer. I just need class which makes my objects events sources. And I'm wondering why Announcer is bad for this? Just look at Announcer definition:
Object subclass: #Announcer
instanceVariableNames: 'registry'
classVariableNames: ''
poolDictionaries: ''
category: 'Announcements-Core'
"registry" variable is instance of SubscriptionsRegistry which actually implements all announcements logic. Announcer just adds convenient public api to events subscriptions and delivering. No complex logic. No actual knowledge about how announcements work. And your argument "why you subclass from Announcer" looks to me like why you subclass from SubscriptionsRegistry. But I'm not. Nobody doing it. So i'm not understand why you want another wrapper around Announcer.
(To me "subscriptions" is better name then "registry". And I prefer composition than inheritance too).
There are 3 kinds of roles in context: - subscriber: an object who subscribing for events to receive them later - an event source (the object which announces the event) - an announcer, an object which provides subscription service and through which you can announce events, acting as mediator between 2 parties above the rest, like registry, Announcement (as class) and subscriptions is implementation detail. The main reason for using Announcements model is to have decoupling between event source (the place/object , which producing events) and its handlers. And announcer provides such decoupling. That means, both subscribers and event source(s) don't need to have direct knowledge about each other, all they need is to use same announcer to establish communication channel. Then, subscribers don't really care who triggered an event and why/where while event source don't really cares who will handle the event(s), in what order or how many of them there. Now, what happens when you mixing roles and treating announcer as an event source? (and by subclassing from Announcer you doing that). When you merge event source and announcer, then your subscribers are forced to have direct access to event source, and that means you actually not using/need decoupling at all. In this regard, my question: why then you using Announcements model at all? Because it is there, or because there should be only one? I don't think that either of these reasons are valid. When you don't need decoupling , i do not see much value in using Announcements. I would implement/use something else then. -- Best regards, Igor Stasenko.