Re: [OO design] Objects VS Datastructures

"Simon Vandemoortele" <[e-mail]> wrote
in message news:Zcdwa.1038$[e-mail]...

> The problem I see in this setup is that my 'Objects' are very passive;
> they are not much more than datastructures with an attitude. Their whole
> interface consists of setters and getters. I've been wondering if this
> is still OO ? Shouldn't I be sending 'messages' instead of "taking some
> 'Object', pulling out some information to shove it somewhere else" ?

That is a good observation. Many OO designs fail partially because designers
say - wow this is an thing in the problem domain. It has name so it must be
an object. Thus we create a class for that object and figure out how to
relate it to other objects.
When designing properly, it is often discovered that non-obvious entities
are the real objects in the problem domain.

For example the address book could have an object called
ContactUpdateManager. This manager would server a single client and
coordinate its efforts with other ContactUpdateManager objects, or possibly
with other UpdateManagers that updates non-contact information. Note: this
is just an example. I'm not sure it would actually be smart to create
UpdateManagers - it's just a different perspective.

To the question about datastructures:
In a functional programming language such as OCaml, you would typically have
datastructures instead of objects. Instead you have a family of functions
that operate on these datastructures. If you want to map this view onto
objects again, you get a kind of manager style object that manages the
datastructure, not a single data entity. I guess this is why functional
programming is relatively successfull (not popular, just successful).

When I first learned Ruby, I wrote a pet text adventure program. Ruby was
very good at this. But I didn't create a single object of a class I had
designed. I used lots of arrays and hashes. It would have been death by
objects to do the same with a class for every thing I made. When I
eventually made it socket enabled so I could connect via telnet, I realized
I needed to have multiple instances. Thus I wrapped all the code in one
large Adventure class and made an instance for each connection. Had I
created multiple players in the same game, I would problably have had Player
objects and Game objects. But the zillions of commands, verbs, rooms,
relations between rooms etc. was much better handled by datastructures.

So I  say be conservative with object creation. Use it when it helps, but
don't make everything an object.
Note: Ruby's Everything is an object, has to do with consistency of the type
system it doesn't mean you should go out and create a new class for every
piece of data.

It's interesting to follow you observertations throughout the project. You
are touching the essential problems of good software design instead of just
mindlessly coding along.

Mikkel