
Revisiting POODIR
Code is easy, I was told, because it is mutable — it will always be growing and changing. It is hard because you create the maze that you solve and your tools can become your torture devices
Here are a few things I learned in that respect from revisiting Practical Object-Oriented Design in Ruby (POODIR).
This is a read for a practising professional that has been heads-down a bit too long, or a new graduate who wants to understand some of the more enigmatic comments on their pull requests. It can be read on a weekend and will broaden perspective. The book is no more static in its approach than a development project and no more judgemental that a good fellow code reviewer.
- The practicality comes from a succinct set of ‘retries’ on individual concepts, enhancing them with each iteration, finding the new advantages and flaws; in other words the way a Developer learns and grows. It is as short as this format could allow and still cover the territory of object oriented design and test
- It centralizes the dichotomy of object oriented design — composition versus inheritance but in the end emphasizes that the Message is what matters — communication between structures is what leads to joy in development
This is not a prescriptive journey, the core concept is that the reader understand the trade-offs and why they continuously re-appear in every development process — software development is a holistic process and choices are pragmatic — meaning they are made based on the best information available at the time, and on the fundamental assumption that software will be refactored when new information comes along.
Some of the main metrics that the author emphasises is ‘cost effectiveness’, i.e. time cost now and time cost in the future, and Joy, which is measured in the ease of manipulating and traversing a code base to adapt it to new capabilities. These are the two most meaningful things a developer can measure, since they impact every day of their careers.
Three big takeaways
- Test the behaviour of objects through their public interfaces. Question the existence of extensive private behaviour in a given moving part of your design. Question too much depth or depth breadth in a hierarchy
- Understand that there is a spectrum along which you make architecture choices every day — between composition and inheritance, between now and the future. The balance is struck in terms of time invested now versus time needed for future changes
- Code is mutable — it will change, and you may or may not be the one to have to change it. Make this process of refactoring a joy, rather than a pain through self-documenting architecture, interfaces, and tests
