The day's endpoint was an invited talk by Robert
Uncle Bob
Martin. In a twist, Bob let us choose the talk we wanted to
hear: either his classic "Advanced Principles of
Object-Oriented Class Design" or his newer and much more
detailed "Clean Code".
While we thought over our options, Martin started with a
little astronomy lesson that involved
Henrietta Levitt,
globular clusters, distance calculations, and the width of
our galaxy. Was this just filler? Was there a point related
to software? I don't know. Maybe Bob just likes telescopes.
The vote of the group was for Principles. Sigh. I wanted
Clean Code. I've read all of Bob's papers that underlie
this talk, and I was in the mood for digging into code.
(Too many hours pushing papers and attending meetings will
do that to a guy who is Just a Programmer at heart.)
But this was good. With some of the best teachers, reading
a paper is no substitute for the
performance art
of a good presentation. This blog can't recreate the talk,
so if you already know Martin's five principles of OO design,
you may want to move on to his
latest ruminations
on naming.
At its core, object-oriented design is about managing
dependencies in source code. It aims to circumvent
the problems inherent in software with too many dependencies:
rigidity, fragility, non-reusability, and high viscosity.
Bob opened with a simple but convincing example of a copy
routine, a method that echoes keyboard input to a printer,
to one of his five principles, the Dependency Inversion
Principle. In procedural code, dependency flows from the top
down in a set of modules. In OO code, there a point where
top-down dependencies end at an abstraction like an interface,
and the dependencies begin to flow up from the details to the
same abstractions. My favorite detail in this example was
his pointing out that getch() is polymorphic method,
programmed to the abstractions of standard input and standard
output. ("Who needs all that polymorphism nonsense," say my
C-speaking colleagues. "Let's teach students the fundamentals
from the bottom up." Hah!)
Martin then went through each of his five principles, including
DIP, with examples and a theatrical interaction with his
audience. Here are the highlights to me:
Side lesson: There is no perfect way to write code. There are always competing forces. There is a conflict between the design principle encapsulation and the SRP. To ensure the SRP, we may need to relax encapsulation; to ensure encapsulation, we may need to relax the SRP. How to choose? All other things equal, we should prefer the SRP, as it protects us from a clear and present danger, rather than from potential bad behavior of programmers working with our code in the future. A mini-sermon on overprotective languages and practices followed. The Smalltalk programmers in the audience surely recognized the theme.
Side lesson: OO design works best if you can predict the future, so that you can select the abstractions which are likely to change. We can predict the future (or try) either by thinking hard or by letting customers use early versions of the code and reacting to the actual changes they cause. Ceteris paribus, OO design may be better than the alternatives, but it still requires work to get right.
Side lesson: Another conflict we face when we program is that between flexibility and type safety. As with the SRP and encapsulation, to achieve one of flexibility and type safety in practice, we often have to relax the other. Martin described how the trend toward test-driven design and full-coverage unit testing eliminates many of the compelling reasons for us to seek type safety in a language. The result is that in this competition between forces we can favor flexibility as our preferred goal -- and choose the languages we use differently! Ruby, Python, duck typing... these trends signal our ability to choose empowering, freeing languages as long as we are willing to achieve the value of type safety through the alternate means of tests.