2013/7/22 Stéphane Ducasse <stephane.duca...@inria.fr> > 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 >
I agree with your examples. And I never build my domain "container like classes" as subclass of OrderedCollection (or friends). But Announcer to me is different concern. It is like subclassing Object as Tudor said. What is all api of Announcer? > > Announcer allSelectors > It should be "Announcer selectors" (it is 16 methods). And I think it is wrong to name all methods of class as API. And I think Announcer API can be reduced to just 5 methods: #announce:, #on:do, #subscribe:send:to:, #unsubscribe:and #week. All others are private or just convenient aliases (maybe already deprecated). And this 5 methods is exactly what I need to subscribe on "event service" with enough flexibility. So when I implement my domain "event source" I need superclass which will supply to my service such nice API. And now there is only Announcer class for this. I were look at Announcer hierarchy. What do you think about SystemAnnouncer class? It has strange implementation. It is subclass of Announcer and it has another announcer instance named "private".
