> And what I should do if I want Customer which can trigger events? then ask yourself about the API of your customer Do you want the full API of Announcer? I doubt.
> Do you think "EventSource subclass: #Customer" make any difference? Or do > you think we should never use inheritance to make domain announcer classes? > What the existed alternative? I don't want always add announcer instance and > couple equal methods any time I need it. Think about API not about code reuse. Think about polymorphic objects. Each time you subclass from Announcer ALL the API should make sense. We should use subclassing when you can potentially replace instance of the superclass by instance of the subclasses at least from the API point of you and that existing code calling the superclass still somehow work. > In practice in both cases my domain classes will never override methods from > "events support superclass". > > And to me name "Announcer" is exactly events source. Is my english so bad > here? Maybe we should rename it to "AnnouncerMediator" and real Announcer > class? I like the distinction made by igor. I do not want to think in terms of Registry. I do not care in fact. I care that I have a class that can register and announce. > > Best regards, > Denis
