TITLE: Primitive Obsession and Balance
AUTHOR: Eugene Wallingford
DATE: May 31, 2005  4:58 PM
DESC: Primitive Obsession is a smell, for sure.  But let's not go too far...
-----
BODY:
Recently, Chris Wheeler posted a thoughtful blog
entry called
<A HREF="http://www.agilelectric.com/2005/05/26/my-favourite-smells/">
   My Favourite Smells</A>,
which described only one smell, but one every
OOP programmer knows deep in his soul: using
a primitive data type instead of a domain-specific
type.  James Shore calls this smell
<A HREF="http://www.jamesshore.com/Blog/PrimitiveObsession.html">
   Primitive Obsession</A>,
and Kevin Rutherford calls it
<A HREF="http://cgi.bramwell.plus.com/krblog/2005/05/primitive_featu.html">
   Primitive Feature Envy</A>.

Chris has been justifiably lauded for starting a
conversation on this topic.  I find this smell in my
programs and even in many of the programs I read from
good OOP programmers.  When programmers are first learning
to write object-oriented programs, the tendency to write
code in terms only of the primitive data types is hard
to shake.  Who needs that <TT>Piece</TT> class, when a
simple integer flag taking values from 1 to 4 will do
just fine?  (Heck, we can always
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-05.html#e2005-05-17T08_31_51.htm">
   use Hungarian Notation</A>
to make the semantics clear. :-)  When students come
to see the value of that <TT>Piece</TT> class, they
begin to see the value of OOP.

That said, we have to be careful to remember that this
smell is not an absolute indicator.  There is an inherent
tension between the desire to create classes to model the
domain more closely and the desire to
<A HREF="http://c2.com/cgi-bin/wiki?DoTheSimplestThingThatCouldPossiblyWork">
   do the simplest thing that could possibly work</A>.
If I try to wrap every piece of primitive data in its
own class, I can very quickly create a lot of unnecessary
code that makes my program worse, not better.  My program
looks like it has levels of abstraction that simply aren't
there.

That's not the sort of thing that Chris, James, and Kevin
are advocating, of course.  But we need to learn how to
strike the proper balance between Primitive Obsession
and Class Obsession, to find the abstractions that
make up our domain and implement them as such.  I think
that this is one of the reasons that Eric Evans' book
<A HREF="http://domaindrivendesign.org/book/">
   Domain-Driven Design</A>
is so important: it goes a long way toward teaching us
<STRONG>how</STRONG> to make these choices.  Ultimately,
though, you can only grok this idea through experience,
which usually means doing it wrong many times in both
directions so that your mind learns the patterns of
good designs.  As Chris', James', and Kevin's articles
all point out, most of us start with a predilection to
err on the side of primitives.

One way to push yourself to learn this balance is to
use the <A
HREF="http://www.cs.uni.edu/~wallingf/patterns/pedagogical/three-bears.html">
   Three Bears pattern</A>
first described by Kent Beck to create situations in
which you confront the consequences of going too far
one way or the other.  I think that this can be another
one of those programming etudes that help you become a
better programmer, a l&aacute; the
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-01.html#e2005-01-24T10_01_44.htm">
   Polymorphism Challenge</A>
that Joe Bergin and I used at
<A HREF="http://www.ithaca.edu/sigcse2005/">
   SIGCSE 2005</A>,
in which we had folks rewrite some standard programs
using few or zero <TT>if</TT> statements.

In order to feel the kind of effects that Chris describes
in his article, you have to live with your code for a
while, until the specification changes and you need that
tolerance around your masses.  I think that the folks
running the
<A HREF="http://icfpc.plt-scheme.org/">
   ICFP 2005 programming contest</A>
are using a wonderful mechanism to gauge a program's
ability to respond to change.  They plan to collect the
contestants' submissions and then, a couple of weeks
later, introduce a change in the spec and require the
contestants to adapt their programs on an even shorter
deadline.  What a wonderful idea!  This might be a nice
way to help students learn the value of adaptable code.
Certainly, Primitive Obsession is not much of a problem
if you never encounter the need for an abstraction.

Ron Jeffries posted a message to the XP discussion list
earlier today confessing that one of his weaknesses as a
programmer is a tendency to create small classes <EM>too
quickly</EM>.  As an old Smalltalker, he may be on the
opposite end of the continuum from most folks.  But we
need a good name for the smell that permeates his code,
too.  My "Class Obsession" from above is rather pedestrian.
Do you have better name?
<A HREF="mailto:wallingf@cs.uni.edu">
   Please share</A>...
Whatever the name, I suspect that Ron's recognition of
his tendency makes it easier for him to combat.  At least
he knows to pay attention.

Chris's article starts with the idea of favorite smells
but then settles on one.  It occurs to me that I should
tell you my personal favorite smell.  I suspect that it
relates to duplication; my students certainly hear that
mantra from me all the time.  I will have to think a bit...
-----