Sandi Metz wrote the book titled “Practical Object-Oriented Design in Ruby”. As the title implies this book is about object oriented design using Ruby. After reading a couple of chapters, I decided to share my thoughts about this book but I wanted to do it a little bit different. I want to take each chapter and reflect on the contents. I don’t want to write a book review with a few words. I want to take the time and do it right.
For chapter 1, Sandi starts with the phrase “The world is procedural” but the next paragraph she introduces us to the world as software developers see the world. She writes “The world is also object-oriented”.
I agree with her view of the world as being object-oriented. Everything is an object and they must interact with other objects. She calls these interactions “messages”. I never saw these interactions as being messages. I always saw them as calling a method on my object and getting a response back. I like the word message because it allows you to explain your design to non-technical people.
She also shares the benefits of having a well designed application and contrasting it with the perils of maintaining a poorly designed one. In one hand, you have the joy and pleasure to work in a well designed app and that leads to enjoy the changes introduced by new requirements. You don’t have to modify the entire code base. It is a minimal change. On the other hand, working with a poorly designed application leads to anger and confusion. Imagine having to add a new feature but that change will force you to modify a lot of objects. This is painful and we have experienced the pain with our projects. In the following chapters, she gives us common solutions to these problems.
“Change is unavoidable”, writes Sandi. As software engineers, we know that applications are constantly changing. We must fix this page that suddenly stop working. We got a new requirement for a new feature. We must embrace change and having well designed apps will allow to make those changes without compromising quality or the stability of our project.
She continues with the problem that is introduced when objects and messages know too much about each other. The more they know about each other, the more tightly coupled the design is. This is what she calls dependencies. In the next chapters, she gives us tool to manage these dependencies.
She also introduces Design Patterns and the Gang of Four. If you are an experienced software developer, you must know what Design Patterns and who the Gang of Four are. But to give you a quick refresher, the design patterns are a set of solutions to common software problems. The Gang of Four are Erich Gamma, Richard Helm, Ralph Johnson, and Jon Vlissides. They got together and wrote a book on software patterns in 1995. Both of these resources have helped many organizations with their design. They took time to study common problems and gave us solutions to these problems. These resources are a must have for any software company.
We know that having no design at all is a recipe for disaster. But also having a over-designed application. I have experiences with architects that over-engineered apps and requesting a change required lots of effort. Sandi makes a good point about bringing together design and code. If there is no constant feedback from the designer and coder, this is a recipe for disaster.
Summary
In conclusion, I think that Sandi does a great job introducing her book. She starts with getting our thoughts in place, and asks us to “start thinking in terms of objects”. Once our mind set is correct, she compares a well design systems with one with on design at all. Then she briefly mentions design patterns, the Gang of Four, and how their contributions will help us with our design. I will have a review of chapter 2 next week.
