On Jul 21, 2013, at 9:27 PM, Denis Kudriashov <dionisi...@gmail.com> wrote:
>
> 2013/7/21 Stéphane Ducasse <stephane.duca...@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
