On Saturday 28 July 2001 09:59 am, you wrote:

>   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?

You look at responsibilities and roles. Why should an Array know anything 
about HTML?

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

This is a choice that is (generally) below the level of Design Patterns.

>   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.)

I think Kent Beck's advice in Smalltalk Best Practice Patterns is good here:

---------
One problem with representing conversion as methods in the object to be 
converted is that there is no limit to the number of methods that can be 
added. The protocol grows and grows without limit. Another is that it ties 
the receiver, however tenuously, with a class of which it would otherwise be 
oblivious.

I avoid the protocol explosion problem by only representing conversions with 
a message to the object to be converted when:

* The source and destination of conversion share the same protocol.

* There is only one reasonable way to implement the conversion.
---------

-- 
Ned Konz
currently: Stanwood, WA
email:     ned / bike-nomad.com
homepage:  http://bike-nomad.com