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).�

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.