Kent Beck’s Implementation Patterns book is an easy and enjoyable read. Many things are familiar, as one would expect from patterns that you’ve encountered before. Others were hmmm – that’s an interesting idea, I hadn’t thought of like that before – which I always enjoy.
Four things stood out in particular for me.
I’ve always been a single return kind of guy. It is what I was introduced to. I was coding in C/C++ so you needed to have a clean-up phase inside the method if you had put anything on the heap. And debugging was easier when working in assembly to debug your code if there was only a single return. And Dykstra said it was a good idea.
But the way Kent Beck describes guard clauses just makes sense. It combines really well with the example in Clean Code around separating the error handling concern from what the code is actually intending to do and achieving Single Responsibility. It makes things simpler.
The context of needing a single return is embedded in longer methods/functions and a world where you didn’t have garbage collecting. Today there is a move to keep methods below 10 lines, so if you exit early, well you were exiting on average in 5 lines anyway so it should make sense to read the code and understand. The context in which a single return made sense did possibly exist. But if you write short methods and return using guard clauses to show non-standard paths the clarity and readability of the code seems to be greater.
Cleaning too quickly
Two patterns stood out to me as being more difficult to see if you clean your code too early. Potentially a better design is being obscured and cleaning your code a little later might allow that design to emerge more easily.
If you have a few case statements that always branch on the same things, perhaps there is potential for a strategy object – a class for each case statement, implementing the different strategies. Your multiple case statements merge into ensuring the right strategy object is created – probably at object creation time – and then just calling the strategy field to do the work. No more ugly if trees or case statements.
When a class starts to get large and parts of it start to do a bunch of things that are related, you might have a case for extracting an object method – an object that implements a complex method for the original class.
I particularly enjoyed the book’s description of the refactoring process to see and draw out an object method. The key being that cleaning up the code by breaking it into smaller pieces can obscure the need for the object method. The first step of the refactoring is to merge it all together into one big method and then extract it to the new class.
Maybe leaving it a little while to see the design is a good idea. Otherwise if you work to eradicate the ifs and cases you might miss that you could use strategy fields. If you clean up your methods too much, you might need to undo that work in order to better see and extract an object method.
Double dispatch is cool. I knew about it and have used it, but I often forget about it as a tool that can solve OO problems. It was good to be reminded of it, and to dig a little into the examples and think on some examples of my own where it made sense – or not.
The discussion around how you think differently if you work on a framework stuck with me. I started in a large organisation which essentially was a framework – an operating system. All code was paranoid and couldn’t fail. Everything had to check inputs everywhere. This embedded me with a certain way of thinking about code right from the beginning of my career. This was a very valuable experience, but it didn’t teach me the value of doing the simplest thing to achieve the specific business goal. The business goal wasn’t generally a specific quantifiable business requirement but a framework one of providing non-crashable, functional, non-hackable, useful APIs. It has taken me many years of working on business applications to unlearn this. It was great to see the book highlight the difference in the way you think about code when others are actively consuming it as a framework.
How you code comes back to what you’re valuing. In frameworks it is keeping the consumer of the framework working (hopefully). In business code where all the code is controlled, ruthless culling of old code is able to be done in the interests of simplicity as the code is (hopefully) in the control of the coder.
Recommended if you’re a thinking coder
I’d recommend reading Implementation Patterns if you’re keen to continue understanding how you code and why you make the design decisions you make, or if you’re looking for a few new options. I found it useful reading each pattern and asking – where would I use it, where wouldn’t I – and really understanding the value of the pattern. The book is very readable and certainly has helped me a little further on my road to digging into my thinking around coding ideas. That is really valuable to me as a thinking coder.