Practical Object Oriented Design in Ruby by Sandi Metz | BlueDiapente - Lilibeth De La Cruz


Practical Object Oriented Design in Ruby by Sandi Metz

Sandi Metz's "Practical Object Oriented Design in Ruby" or POODR as it is sometimes called in the community was an enjoyable read.

As a software developer with decades of experience, she has experienced the pains of unmanageable code and the joys of well written code. This shows in her writing. She comes off as incredibly humble, knowledgeable and passionate about design. She also presents design as something we do everyday as we build and shape our applications every day.

The style is a lot more accesible that many other books I've read on the topic and it used a wonderful conversational style that allows for an easy and entertaining read. Well known rules like the Liskov Substitution Principle and The Law of Demeter are explained clearly and evaluated for what their spirit is, instead of seeing them as written in stone.

One of the core concepts mentioned on the book is that, code should be TRUE:

  • Transparent: The consequences of change are visible and predictable.
  • Reasonable: The cost of adding a new feature is proportional to its value.
  • Usable: Code can be used in other places and for different purposes other than your original intention.
  • Exemplary: Other developers (maybe even future you) tend to imitate the already existing code. Make sure you write code in a style that is worthy of being repeated.

The book also advices to avoid postponing decisions until you have more information. It can be tricky advice to follow though, since identifying when it is the right time to make that decision only comes with OO design experience as well as domain knowledge.

I really liked the emphasis throughout the book in the issue of 'cost' and how this whole OO design thing is here to help us decrease the 'cost' in developing and maintaining applications in the real world. It is very easy for a programmer that loves his job as sees it as a craft to lose sight of the big picture sometimes. When that happens, you start refactoring code unnecessarily, having some abstract beauty as a goal. It is important to keep in mind that we need to evaluate whether the time we will invest making changes is necessary and how much flexibility it could give us in the future.

I found interesting the way she considered tests to be the first reuse of the code and how code that was hard to test, would also be hard to reuse.

The only thing I didn't like much about the book was that it used bycicles as the domain for all examples in the book. I don't know a lot about bycicles and felt like I couldn't relate and that it got in the way when some technical (for me) cycling terms where used. They are also very concrete real world 'things', while that is not the way things usually are in real world applications. I still think it was probably a good thing she picked that domain if it was one she felt comfortable with and allowed her to express her ideas more freely.

While the book doesn't offer any groundbreaking new ideas, it does present OO concepts in a fresh and interesting way. It serves as great insight and personally as a reminder of how much I still have to learn.

Go read it!