TITLE: Patterns that Break the Rules
AUTHOR: Eugene Wallingford
DATE: July 30, 2004 12:26 PM
DESC: elementary patterns and design rules and heuristics
-----
BODY:
I ran across an old 'thought piece' (*) a couple of days ago that
reminded me of a discussion that was common at my early PLoPs: how
some design patterns 'break the rules' of object-oriented design.

Among the GoF patterns, Bridge and Singleton are often cited as
patterns that violate some of the principles of OOD, or at least
the heuristics that usually indicate good designs.

On the other hand, some of the GoF patterns don't violate OOD
design principles.  Indeed, they seem to specialize or at least
<I>illustrate</I> of OOD design principles.  Strategy, Adapter,
and State come to my mind.  I remember a comment that Bobby Woolf
made to me at PLoP'96 or '97 when he came across such a pattern
in a workshop: "That's not a pattern.  It's just object-oriented
programming."

Of course, if a particular configuration of classes and methods recurs
in a particular context, then acknowledging that recurrence has value
has a tool for teaching and learning.  What is obvious to one reader
is not obvious to every reader.
(<A HREF="http://www.testing.com/cgi-bin/blog">Brian Marick</A>
wrote an interesting note on how this applies to <A
HREF="http://www.testing.com/cgi-bin/blog/2003/08/29#reader-response">comments
in code</A>.)  Such a pattern also has value as a part of a pattern
language that documents something bigger.

Back in those days, Jim Coplien was just beginning to talk about the
idea of symmetries, symmetry breaking, and their relationship to what
is and isn't a pattern.  I wish I could remember some of the pragmatic
criteria he used for classifying the GoF patterns in this way, but
my memory fails me.

One can see this idea at work with patterns of imperative programming,
too.  Control structures break the "symmetry" of sequential processing,
while some looping patterns illustrate common design rules (e.g.,
Process All Items) and others violate more general rules (e.g.,
Loop and a Half).

The most important point made in this thought piece was a pedagogical
one, made in the conclusion: that relating patterns to more general
design rules and heuristics helps students learn <I>both</I> better.
This should be obvious to us, but like many patterns needs to be
said explicitly every once in a while.  Relating patterns to more
general design rules and heuristics creates a richer context for both.
It helps students learn to make better design decisions through a
deeper understanding of the forces at play.

(*) Joseph Lang et al., "Object-Oriented Programming and Design Patterns",
    SIGCSE Bulletin 33(4):68-70, December 2001.
-----