TITLE: Relationships, Not Characters
AUTHOR: Eugene Wallingford
DATE: November 02, 2010 11:00 AM
DESC: 
-----
BODY:
Early in his book "Impro",
<A HREF="http://www.keithjohnstone.com/">
   Keith Johnstone</A>
quotes playwright
<A HREF="http://www.doollee.com/PlaywrightsB/bond-edward.html">
   Edward Bond</A>
to the effect:

<BLOCKQUOTE><EM>
Drama is is about relationships, not about characters.
</EM></BLOCKQUOTE>

This immediately brought to mind Alan Kay's insistence
that object-oriented programmers too often focus so much
on the objects in their programmers that they lose sight
of something more important: the space between the objects.
A few years ago, I wrote about this idea in an entry called
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-04.html#e2005-04-07T07_49_17.htm">
   Software in Negative Space</A>.
It remains one of my most-read articles.

The secret to good OO design is in the <I>ma</I>, the web
of relationships that make up a complex system, not in the
objects themselves.

I think this is probably true of good design in any style,
because it is really about how complex systems can manage
and use encapsulation.  The very best OO design patterns
show us how multiple objects interact via message passing
to resolve a thorny set of forces.  The individual objects
don't solve the problem; the solution lies in their
interfaces and delegation of responsibility.  We need to
think about our designs at that level, too.

Now that functional programming is
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-10.html#e2010-10-30T13_01_58.htm">
   receiving so much mainstream attention</A>,
this is a good time to think about when and how good
functional design is about relationships, not (just)
functions.  A combinator is an example: the particular
functions are not as important as they way they hook
together to solve a bigger problem.  Designing functions
in this style requires thinking more about the interfaces
that expose abstractions to the world, and how other
modules use them as service, and less about their
implementation.  Relationships.
-----