TITLE: OOP As If You Meant It
AUTHOR: Eugene Wallingford
DATE: December 06, 2019  2:42 PM
DESC: 
-----
BODY:
 This morning I read an old blog post by Michael Feathers,
<A HREF="https://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html">
   The Flawed Theory Behind Unit Testing</A>.
 It discusses what makes TDD and Clean Room software development
 so effective for writing code with fewer defects: they define
 practices that encourage developers to work in a continuous
 state of reflection about their code.  The post holds up well
 ten years on.

 The line that lit my mind up, though, was this one:

<BLOCKQUOTE><EM>
 John Nolan gave his developers a challenge: write OO code with no getters.
</EM></BLOCKQUOTE>

 Twenty-plus years after the movement of object-oriented programming
 into the mainstream, this still looks like a radical challenge to
 many people.  "Whenever possible, tell another object to do something
 rather than ask for its data."  This sort of behavioral abstraction
 is the heart of OOP and the source of its design power.  Yet it is
 rare to find big Java or C++ systems where most classes don't provide
 public accessors.  When you open that door, client code will walk in
 -- even if you are the person writing the client code.

 Whenever I look at a textbook intended for teaching undergraduates
 OOP, I look to see how it introduces encapsulation and the use of
 "getters" and "setters".  I'm usually disappointed.  Most CS faculty
 think doing otherwise would be too extreme for relative beginners.
 Once we open the door , though, it's a short step to using (gulp)
 <TT>instanceof</TT> to switch on kinds of objects.  No wonder that
 some students are unimpressed and that too many students don't see
 any much value in OO programming, which as they learn it doesn't
 feel much different from what they've done before but which puts
 new limitations on them.

 To be honest, though, it is hard to go Full Metal OOP.  Nolan was
 working with professional programmers, not second-year students,
 and even so programming without getters was considered a challenge
 for them.  There are certainly circumstances in which the forces at
 play may drive us toward cracking the door a bit and letting an
 instance variable sneak out.  Experienced programmers know how to
 decide when the trade-off is worth it.  But our understanding the
 downside of the trade-off is improved after we know how to design
 independent objects that collaborate to solve problems without
 knowing anything about the other objects beyond the services they
 provide.

 Maybe we need to borrow an idea from the
<A HREF="https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/">
   TDD As If You Meant It</A>
 crowd and create workshops and books that teach and practice OOP as
 if we really meant it.  Nolan's challenge above would be one of the
 central tenets of this approach, along with the
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2012-02.html#e2012-02-19T12_17_41.htm">
   Polymorphism Challenge</A>
 and other practices that look odd to many programmers but which are,
 in the end, the heart of OOP and the source of its design power.

~~~~~

 If you like this post, you might enjoy
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-09.html#e2011-09-08T20_19_25.htm">
   The Summer Smalltalk Taught Me OOP</A>.
 It's isn't about OOP itself so much as about me throwing away systems
 until I got it right.  But the reason I was throwing systems away was
 that I was still figuring out how to build an object-oriented system
 after years programming procedurally, and the reason I was learning
 so much was that I was learning OOP by building inside of Smalltalk
 and reading its standard code base.  I'm guessing that code base
 still has a lot to teach many of us.
-----