TITLE: When "What" Questions Presuppose "How"
AUTHOR: Eugene Wallingford
DATE: November 03, 2012 11:17 AM
DESC: 
-----
BODY:
John Cook wrote about times in mathematics when
<A HREF="http://www.johndcook.com/blog/2012/11/01/maybe-you-dont-need-to/">
   maybe you don't need to</A>
do what you were asked to do.  As one example, he used remainder
from division.  In many cases, you don't need to do division,
because you can find the answer using a different, often simpler,
method.

We see a variation of John's theme in programming, too.  Sometimes,
a client will ask for a result in a way that presupposes the
method that will be used to produce it.  For example, "Use a stack
to evaluate these nested expressions."  We professors do this to
students a lot, because they want the students to learn the
particular technique specified.  But you see subtle versions of
this kind of request more often than you might expect outside the
classroom.

An important part of learning to design software is learning to
tease apart the subtle conflation of <B>interface</B> and
<B>implementation</B> in the code we write.  Students who learn
OO programming after a traditional data structures course usually
"get" the idea of data abstraction, yet still approach large
problems in ways that let implementations leak out of their
abstractions in the form of method names and return values.  Kent
Beck talked about how this problem afflicts even experienced
programmers in his blog entry
<A HREF="https://www.facebook.com/notes/kent-beck/naming-from-the-outside-in/464270190272517">
   Naming From the Outside In</A>.

<A HREF="http://sourcemaking.com/refactoring/primitive-obsession">
   Primitive Obsession</A>
is another symptom of conflating what we need with how we produce
it.  For beginners, it's natural to use base types to implement
almost any behavior.  Hey, the extreme programming principle
<A HREF="http://en.wikipedia.org/wiki/You_ain't_gonna_need_it">
   You Ain't Gonna Need It</A>
encourages even us more experienced developers not to create
abstractions too soon, until we know we need them and in what
form.  The convenience offered by hashes, featured so prominently
in the scripting languages that many of us use these days, makes
it easy to program for a long time without having to code a
collection of any sort.

But learning to model domain objects as objects -- interfaces
that do not presuppose implementation -- is one of the powerful
stepping stones on the way to writing supple code, extendible
and adaptable in the face of reasonable changes in the spec.
-----