TITLE: "What Should It Be?"
AUTHOR: Eugene Wallingford
DATE: January 31, 2014  3:13 PM
DESC: 
-----
BODY:
When asked to design and implement a program, beginning programmers
often aren't sure what data type or data structure to use for a
particular value.  Should they use an array or a list?  Or they've
decided to use a record but can't decide exactly what fields to
include, or names to give them.

"What should it be?", they ask.

I often have a particular implementation in mind, based on what
we've been studying or on my own experience as a programmer, but I
prefer not to tell them what to do.  This is a great opportunity
for them to learn to think about design.

Instead, I ask questions.  "What have you considered?"  "Do you
think one or the other is better?"  "Why?"

We discuss how so often there is no "right" answer.  There are
merely trade-offs.  They have to choose.  This is a design
decision.

But, in making this decision, there's another opportunity to learn
something about design.  They don't have to commit now and forever
to an implementation before proceeding with the rest of their
program.  Because the rest of the program shouldn't know about
their decision anyway!

<B>They should make an object that encapsulates the choice</B>.
They are then able to start building the rest of the program
without fear that it depends on the details of their design choice.
The rest of the program will interact with the object in terms of
what the object <EM>means</EM> in the program, not in terms of how
it is implemented.  Later, if they change their minds, they will be
able to change the implementation details without disturbing the
rest of the code.

Yes this is basic stuff, but beginners often struggle with basic
stuff.  They've learned about ADTs or OOP, and they can talk
abstractly about abstraction.  But when it comes time to write code,
indecision descends upon them.  They are afraid of messing up.

If I can help allay their fears of proceeding, then I've contributed
something to their work that day.  I even suggest that writing the
rest of the program might even help them figure out which alternative
is better.  I like to listen to my code, even if that idea seems
strange or absurd to them.  Some day soon, it may not.

In any case, they have the beginnings of a program, and perhaps a
better idea of what design is all about.
-----