Hi 2013/7/19 Igor Stasenko <siguc...@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). > then may implement same protocol as in Announcer in it, which will > simply delegate to announcer ivar. > And i bet, you don't want to expose full Announcer protocol there, > while probably you may want to implement some convenience protocols, > which Announcer lacking. > > So, at the end by subclassing from ObjectWithAnnouncer you will be > reusing its capabilities in each and every subclass of it, but by > delegating real job, you are free from worrying about dealing with > implementation detail and exposing unwanted state/protocols to its > users. > > Another aspect of it, is when i see: > > ObjectWithAnnouncer subclass: #MyDomainObject > > it tells me, aha.. so some (at least this one) of his domain objects > having announcers, > and the valid protocols is defined in ObjectWithAnnouncer. > > but when i see > > Announcer subclass: #MyDomainObject > > i starting to be uncertain: is Announcer private there or public? > can i send messages like #basicSubscribe: to your domain object and expect > that > it will be handled correctly? Or do i allowed to subscribe directly at > all, because maybe > domain object has some specific protocol(s) and ways to do that.. > Every such question and uncertainty for coder means more time, more > errors, and less productivity. > > > -- > Best regards, > Igor Stasenko. > >
