Practical Object-Oriented Design: An Agile Primer Using Ruby

by Metz Sandi

Designs that anticipate specific future requirements almost always end badly. Practical design does not anticipate what will happen to your application; it merely accepts that something will and that, in the present, you cannot know what. It doesn’t guess the future; it preserves your options for accommodating the future.

I personally have a bad habit of trying to anticipate what the future change is rather than just leaving open for any change. This almost never works out for me.

In 2001, Laing and Coleman examined several NASA Goddard Space Flight Center applications (rocket science) with the express intention of finding “a way to produce cheaper and higher quality software.”3 They examined three applications of varying quality, one of which had 1,617 classes and more than 500,000 lines of code.

This doesn’t seem very large for an enterprise application and I'd imagine in a verbose language (think C++, Java) the LOC/class isn't bad either.

Metrics software works by scanning source code and counting things that predict quality. Running a metrics suite against your own code can be illuminating, humbling, and sometimes alarming. Seemingly well-designed applications can rack up impressive numbers of OOD violations.

We should try this. Not for places we should fix, just out of curiosity.

Data gets packaged up into variables and then passed around to behavior, which could, frankly, do anything to it. Data is like a child that behavior sends off to school every morning; there is no way of knowing what actually happens while it is out of sight.

This effectively describes FP also, with the caveat that most FP languages make data immutable. FP has been very popular lately so this may not be as bad of a thing as she makes it sound.

Always wrap instance variables in accessor methods instead of directly referring to variables.

Great Ruby advice. There is no cost to this and no reason not to do it. Private attr_accessors and message sends instead of ivar access makes classes much easier to change.

Cog becomes the result of a message send. Implementing this method changes cog from data (which is referenced all over) to behavior (which is defined once). If the @cog instance variable is referred to ten times and it suddenly needs to be adjusted, the code will need many changes. However, if @cog is wrapped in a method, you can change what cog means by implementing your own version of the method.

Being able to add logic to an accessor instead of having to add logic everywhere an ivar is used really saves time.

Do these refactorings even when you do not know the ultimate design. They are needed, not because the design is clear, but because it isn’t. You do not have to know where you’re going to use good design practices to get there. Good practices reveal design.

Definitely agree that the first draft of code is almost never the final draft and usually a couple iterations are needed. Refactoring TOWARDS where you want to go before going there generally helps get to the result quicker. This talk is a great example of that process: https://youtu.be/8bZh5LMaSmE