Protocols without Patterns
Join the DZone community and get the full member experience.Join For Free
Still going through the book Growing Objected Oriented Software Through Tests Having complained a lot about how most books have examples that are facile to the point of uselessness, this book, surprisingly suffers from something of the opposite. The details of each aspect of every refactor are recounted at a play-by-play level a reminiscent of Quincy Cartoon Coroner. Got me thinking about the semantics of protocols and how effective they are at sopping up complexity.
The good side of code like this is it follows the Single Responsibility Principle (Meyer then Uncle Bob). The downside though, at least to me, is that you end up writing a lot of code that basically has one component telling another ‘ok, do this.‘ It so happens that the domain they chose for their example lends itself to this: auctions. Why? Because there really isn‘t much ‘work‘ going on here. We show you something, what the current bid is, you bid higher. The good thing about a model like this is it instructs on things like state management, which can be completely absent from some models. On the testing side, these exchanges are a form of wiring. (Filing this under my ‘let‘s look at a world again that doesn‘t have DI in it.‘)
The downside of examples like this is not a lot of work is getting done and therefore, the most difficult aspects of programming are never really broached. I have said this a million times, but the hardest thing in programming is getting relatively complex models to do complex things without having the structure of their organization collapse into a puddle of goo. This is where patterns really shine. That‘s what they are for: not the interstices, or merely the interconnecting tissue. Most of the design patterns are about how to get things to work together without making a big mess. Granted, creational patterns are collaborating on the process of making something (a non-trivial problem), while behavioral ones are about collaboration between extant entities.
When I get this far into a pile of code and haven‘t seen any patterns, I am thinking either we are making a tinkertoy or the purveyors are mayflies.
How and why does this happen? Well, in technology, we are inventing a lot of the time. Rule #1 of invention is there is not usually a blueprint that someone has given you. Therefore, we enter into the Rumsfeld realm of known/knowns, unknown/knowns and unknown/unknowns. But there‘s another dimension here. Human beings generally feel obligated at the process level, but they leave themselves perhaps too much leeway in how they can fulfill those obligations. I would call this the paying mind syndrome: so long as I am paying mind somewhere, I feel that I am diligently working toward an optimal solution.
You know what else this starts to sound like? Slapstick. [People who think that the early phases of comedy are just full of pratfalls by a bunch of morons are fools. Chaplin, Lloyd, Keaton and Bill Fields were philosophers.] Anyway, especially in Keaton and Chaplin, the standard MO is that the diligent, well-meaning protagonist is trying hard against the forces of calamity and if he should have a victory, it‘s often after a lot of indignities and error. Lloyd, in a lot of ways, is the darkest of the 3 because his films often wander into the realm of the well-meaning guy is a rat drawn in by a corrupt, illusory system. In development, we are also the maze builders, which is one of the funniest things about coding. If you have never lived in a codebase that is a. large and b. 100% of your own making, you are probably the weaker for it. It builds character because when you get lost in the maze, you don‘t just go into the knee-jerk reactive mode of grabbing the town scapegoat and sticking him with sharpened bamboo rods. Probably the one who is closest to what I‘m talking about here, though, is Keaton: in One Week he has to build a house. Each thing he does wrong cascades into other problems. What is slain over and over again in slapstick is the idea that diligent attention to what is right under your nose will get you through. One of the really good things about this book is the concept of the ‘walking skeleton‘ is all about this: if you start by constructing something that does a facsimile of a complete process, this problem is curtailed. Personally, though, I think you have to do this and get about the business of providing the infrastructure for the whole, so I am curious to see why there is an utter absence of complex components.
I really commend the authors of this book for putting such detail, finally, into a book. I am not done so maybe it will move beyond this surface layer and we will start seeing some patterns, and more sophisticated components. I have always held that the JUnit paper by Beck and Gamma called ‘a cook‘s tour‘ was one of the great writings of the last 20 years or so. People have to see things as they evolved. Otherwise, we don‘t learn the, um, yeah: pattern. (BTW, the French literary critic Roland Barthes was a proponent of a school for a while called the Structuralists who believed this more broadly.) The other thing that the authors do stress, that is an important message, is that there is a lot of reworking that is done. Clearly, the Fowler book Refactoring made a big splash, but it was kind of the typical taxonomic gestural conceit and it was years before we got books that showed really serious development as a constant process of refactoring. This book is definitely a member of that camp.
Opinions expressed by DZone contributors are their own.