2013/7/21 St�phane Ducasse
<stephane.ducasse@inria.fr>
> 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.
What is all api of Announcer?
Announcer allSelectors
It is just two methods: #announce: and #on:send:to:.
No!!
this is exactly my point. When you inherit from a class you get its API merged into
the one of your class.
When I need "object with events" I always need this methods. What problem?
We should not use subclassing for code reuse but use subclassing for subtyping (= polymorphic interface).
This is not because we have a dynamically typed language that we should not use subtyping.
Have a look at my lecture there are slides on subtyping.
Compare: OrderedCollection subclass: #Poem
of course a poem is a collection of word. Now it is not a subtype of collection!!!
OrderedCollection subclass: #UniqueOrderedCollection
or compare
OrderedCollection subclass: #Stack
vs.
Stack subclass: #HanoiStack
Think in terms of API and polymorphic objects
Stef