"David Tillman" <dtillman / ozarkaircraftsystems.com> wrote in message
news:5dC87.22$6o1.12239 / e420r-atl1.usenetserver.com...

>   1. The reply from David Alan Black (ruby-talk:18683) got me
>   to thinking a bit about object design.  When two objects
>   interact, how do you decide which object handles the interaction?

This is a very good question. But before you ask it, you should also ask
which objects should you have. Just because you have an array and table (as
in the example below), you do not necessarily want these to be objects - or
you could have them as dump data carriers (events) and have some other
objects doing the intelligent stuff. Refactoring the objectmodel is
particularly worthwile when you start having problems finding a natural way
to express things.

>   It could be that a good OOP design book would clear this up for me,
>   _Design_Patterns_ perhaps?

This book is very good, if you refer to Gamma et.al.
The book does not teach you OO design, but it contains many good solutions
to standard problems (or rather patterns).

You may also be tempted to look at books on UML, but those Rational Rose
related 3 Amigos books I've seen, haven't been impressive.
I did find a book (incidentally from Denmark, like myself) on object
modelling that seemed comprehensible and usable:
"Object Oriented Analysis & Design", Mathiassen et.al., Marko.
http://www.marko-publishers.com/index.asp

Then of course you must not forget the Rumbaugh book "Object Oriented
Analysis and Design". It is a classic has most of the UML concepts (before
it was UML) and is better than later UML books he coauthored. I believe he's
about to release a new book, perhaps and updated version of the original
that is fully UML'ed?

>   Example: in my HTML (HTMLoop) library for Ruby you can either pass
>   an Array to a Table object or you can tell an Array to output itself
>   as a table.  (I think it is convenient to have both as myArray.table
>   returns a string immediately but the Table object waits for a puts,
>   to_s, etc.)

DOM document object model is a pattern for handling documents. If you look
at the MSXML parser, you should see an implementation of this model.
But you may not wan't just to update a document. In the document model you
always add data to a container.
But if you have multiple views that needs to updated when changing the
document, you may need another architecture that allows notification of
changes to be distributed. Gamma has several patterns on such scenarios.

>   3. When I originally wrote HTMLoop for CLOS under Scheme, everything
>   remained an object until final output.

I wouldn't know much about CLOS nor HTMLoop. The idea of everything being an
object is nice in the sense that it adds consistency to a language like
Ruby.
But it is definitely bad to design everything as an object in an object
oriented model. Some objects turn out not to exist, others end up just being
relations between two other objects, and some really is just an event i.e. a
method call / message. But then of cause, you could always discuss the
lifetime management of those object that eventually survive this process.

>   I can see advantages to both methods: If object are formatted as
>   soon as they are put to another object, you can use the same objects
>   repeatedly (with something like Object.flush in between uses), using
>   less memory and so forth.

There is rarely one solution that is best. If you can't see any great
disadvantage in one over the other, then just choose one arbitrarily - we
can't tell you what is best, because it depends on the entire solution. You
may learn that something could have been better. But then you'll know that
the next time.

I like a kind of integrated factory pattern approach: Let the container
create and append a new object. Then it is inserted and initialized with the
bare minimum, including information such as owner document and owner table.
It is usually efficient in allocation. After creation, the user of the
container, then fills additional data into the document. In C++, if I can
get away with it, I do not allow any other kind of insertion, and removal is
only supported by clearing the entire collection. This is not generally
pratical, but for filling documents it is fine, easier to implement and much
less errorprone, especially when you do not have garbage collection or are
working with COM components. In Ruby this is much less of an issue.
Some purists might say that an object model should not depend on the
implementation, conceptually perhaps, but the detailed object interaction
certainly should (IMO).

Mikkel