Smalltalk - inheritance or instance variable

Author

inheritance or instance variable

Guybrush Treepwood

2005-01-10, 8:58 am

When a certain object, for example a PostOffice, has a number of links to
other PostOffice objects and a few other properties, what is the best way
to represent it? Is it to make PostOffice a subclass of Set and make the
other properties instance variables, or to let the set also be an instance
variable and make the PostOffice a subclass of Object.

Esteban A. Maringolo

2005-01-10, 8:58 am

Guybrush Treepwood escribió:
> When a certain object, for example a PostOffice, has a number of links to
> other PostOffice objects and a few other properties, what is the best way
> to represent it? Is it to make PostOffice a subclass of Set and make the
> other properties instance variables, or to let the set also be an instance
> variable and make the PostOffice a subclass of Object.

As I can see it, aPostOffice isn't a Set.

Perhaps it 'has' aSet of "whatever". In that situation, the set
should be an instance var of your object.

As a recommendation, do not subclass just because a re-use of
superclasses implementations.

Subclassing is an specialization of the species above in the hierarchy.

Think in a class as an species definition, all instances (samples)
of that species will be from creation to death, normal instance will
not mutate to another species, so when you think in a class, think
in the lifetime of their instances, and what their are, not only in
the implementation.

Aside that, when you subclass, you're inherithing also the
responsibility for understanding the same messages as the
superclass, which is done "syntactically" by the inheritance
mechanism. But the semantic of that could be different.

Best regards,

--
Esteban A. Maringolo

Normand Mongeau

2005-01-10, 4:00 pm

Here's my take on this topic: you should never inherit your domain objects
from collection classes.

Reason number one is that you cannot later change your kind of collection to
another (which is something that happens more often than you might think).

Another reason is that if you inherit from a given collection class, you
convey too much information about what kind of collection it is. It's way
better to inherit from Object, and implement "type neutral" protocols to
add/remove.

For example, if you inherit from a Dictionary because it's what you want to
store your domain objects into, you'll end up with protocol like #at:put:
and #removeAt: which clearly states that you store as a Dictionary.
Instead, create a Wrapper class that holds a Dictionary instVar and
implement methods like #addPostOffice: and #removePostOffice:, which then
turn around and add/remove to and from the Dictionary instVar. This way, if
you ever change your internal representation from the Dictionary to say a
Set, your API stays the same and you only need change the internal code of
the wrapper class.

Normand
The Objects Consulting

"Guybrush Treepwood" <schemer@hotmail.com> wrote in message
news:41e26479$0$322$ba620e4c@news.skynet.be...
> When a certain object, for example a PostOffice, has a number of links to
> other PostOffice objects and a few other properties, what is the best way
> to represent it? Is it to make PostOffice a subclass of Set and make the
> other properties instance variables, or to let the set also be an instance
> variable and make the PostOffice a subclass of Object.

Guybrush Treepwood

2005-01-10, 4:00 pm

Normand Mongeau wrote:
[color=darkred]
> Here's my take on this topic: you should never inherit your domain objects
> from collection classes.
>
> Reason number one is that you cannot later change your kind of collection
> to another (which is something that happens more often than you might
> think).
>
> Another reason is that if you inherit from a given collection class, you
> convey too much information about what kind of collection it is. It's way
> better to inherit from Object, and implement "type neutral" protocols to
> add/remove.
>
> For example, if you inherit from a Dictionary because it's what you want
> to store your domain objects into, you'll end up with protocol like
> #at:put: and #removeAt: which clearly states that you store as a
> Dictionary. Instead, create a Wrapper class that holds a Dictionary
> instVar and implement methods like #addPostOffice: and #removePostOffice:,
> which then
> turn around and add/remove to and from the Dictionary instVar. This way,
> if you ever change your internal representation from the Dictionary to say
> a Set, your API stays the same and you only need change the internal code
> of the wrapper class.
>
> Normand
> The Objects Consulting
>
> "Guybrush Treepwood" <schemer@hotmail.com> wrote in message
> news:41e26479$0$322$ba620e4c@news.skynet.be...

Thanks, I did think myself this was the best and most natural way, but just
to make sure, I asked the experts. :-)

Sponsored Links