TITLE: Sometimes, Good Design is Simple
AUTHOR: Eugene Wallingford
DATE: December 20, 2013  3:01 PM
DESC: 
-----
BODY:
In
<A HREF="http://blog.plover.com/prog/Moonpig.html">
   an article on the Moonpig billing system</A>,
Mark Dominus writes:

<BLOCKQUOTE><EM>
 Sometimes I see other people [screw] up a project over and
 over, and I say "I could do that better", and then I get a
 chance to try, and I discover it was a lot harder than I
 thought, I realize that those people who tried before are
 not as stupid as as I believed.

 That did not happen this time.
</EM></BLOCKQUOTE>

Sometimes, good design is pretty simple.  Separate interface
from implementation.  Create simple abstraction layers to
separate different levels of functionality.  Encapsulate
data and behavior in objects that circumscribe potential
change.

I liked a few of the specific tactics described, too:

<EM>Don't use raw primitives from the language, even standard
classes</EM>.  "Instead of using raw <TT>DateTime</TT> [a
standard Perl class], we wrapped it in a derived class called
<TT>Moonpig::DateTime</TT>."

<EM>Define convenience functions that hide underlying data
implementations</EM>.  Moonpig does this in several places,
most notably money and time.

<EM>Use mutable data sparingly, and never for values</EM>.
One way Moonpig does this is to implement "values with
history", an idea I first learned from Ralph Johnson in
Smalltalk.  Each new value for an entity is pushed onto an
array.  When a piece of code asks for the current value, it
receives the top of the array.

<EM>Object-oriented programming is centered around objects</EM>.
That means encapsulated behavior.  Other concepts, such as
classes and inheritance, are add-ons.  Dominus is especially
hard on inheritance, based on past experience.  I agree that
it must be used carefully and sparingly.  I like how Moonpig
uses roles to eliminate the need for classes entirely in the
application.

This was a fun read.
-----