In his new book,
Responsible Design for Android - Part 1: Dancing with the SDK, J.B. Rainsberger has the following very interesting section on the the nonsensical classicist/mockist divide:
I end up mixing the two predominant styles of design somewhat
haphazardly. In some places I strive to keep things separate, designing in what some people call
the “London school”, guided by the principles of Presenter-First Design that I first learned from
“Presenter First: Organizing Complex GUI Applications for Test-Driven Development” [1]. In other
places I throw everything into the same spot and use duplication and naming problems to guide my
refactoring, designing in what some people call the “Detroit school”, guided more directly by the
Four Elements of Simple Design [2]. We use the terms “London school” and “Detroit school” to recognise
the people from whom we’ve learned the underlying principles. The book Growing Object-Oriented
Software Guided by Tests, written by distinguished London programmers Steve Freeman and Nat
Pryce, illustrates the “London school” approach centered on strict application of the Dependency
Inversion and Interface Segregation Principles, which involves heavy and highly-effective use of
test doubles. Detroit-adjacent programmers Ron Jeffries and Chet Hendrickson (along with several
non-Detroit-adjacent programmers like Joshua Kerievsky, James Shore and Arlo Belshee) exemplify
the “Detroit school” approach which centers on a more intuitive and direct application of the Four
Elements of Simple Design, in which they avoid test doubles and use the resulting tension to guide
them towards designs that better reflect the Single Responsibility Principle. Many commentators
see this as schism, but I don’t. As you’ve seen in this book so far, I use and value both approaches,
although I don’t agree with some of my colleagues’ disdain for test doubles. I prefer not to make
this an issue of “to mock or not to mock”, since that takes focus away from where I think it belongs.
I distinguish the London and Detroit schools a different way: the Detroit school approach favors
those who like to build big things, then break them apart as they become unwieldy; but the London
school approach favors those who like to build little things, then put them together as they exhibit
properties of belonging together. While I see many authors² claiming that either approach objectively
outperforms the other, I can’t agree. As with most such debates, I find I have better results from
knowing and practising both approaches when they seem to fit the situation. Broadly speaking, I
use the London school approach when I feel confident in making one or two up-front high-level
design (“architecture”) decisions, such as “I will use MVC/MVP to design this part of the system” or
“I will model these interactions as publish/subscribe events instead of direct method invocations”;
I use the Detroit school approach when I don’t feel confident about making those decisions. The
London school approach feels more like methodical, safe, steady design, whereas the Detroit school
approach feels more exploratory or meandering (in the good sense, like wandering through a garden,
unworried about the path, trusting that I’ll get where I need to go). Some critics of the Detroit
school dislike the feeling of having to forget what they already know about design and re-discover
everything from first principles; some critics of the London school feel that test doubles lock their
design in and resist change. I see it another way: the Detroit school allows me to meander safely
when I have a general idea of the destination, but an unclear picture of the route; the London school
encourages me to build tiny things and put them together, and when I find that a piece needs to
change shape, I can throw that piece away and design a new one in its place without paying a
prohibitive cost for it. I think of the London school approach as a shortcut that I can take when I
think I recognise what I need to build and the Detroit school approach on which I can fall back when
I just don’t know what to do next. Thus, I benefit the most from practising both, feeling comfortable
with both, and even feeling comfortable refactoring from one style of design to the other. Please
don’t limit this question in your mind to “mocks suck” or “mocks rock”, no matter how pithy you
find those two slogans.
Philip
On Sunday, 23 June 2013 08:31:23 UTC+1, philip schwarz wrote: