Setup

Like with The Goal, Object Design is a book which I was recommended some time ago as a classic, and finally went and read it. Two books of my list finished in the last weeks. Only a few hundred to go.

The book

The book was written by Rebecca Wirfs-Brock and Alan McKean. It is organized in ten sections, moving from concept to realization, introducing the idea of Responsibility-Driven Design, to considerations when you design. The flow was easy. I have to confess it took me a while to read it. But I think that has more to do with me not keeping the speed as I used to.

The review

Let’s start with the fact that I have read this book after I knew most of the concepts that are written in the book (always great to have colleagues that care about learning) . Nonetheless, if you are not experienced enough this is a book that you must read. As a TL;DR, I read this book in digital format through O’Reilly Leaning and now I want a hardback copy of it.

For me, the main breaking idea, over everything else, is that classes DO NOT have to correspond to objects in the real world. I am pretty sure that way before I read this book, I read some comment from Rebecca Wirfs-Brock to the effect (but with my memory, I can’t be sure of when or what). It corrects one of the worst teaching moments that I had back in Spain when I was doing my college course (Técnico Superior, similar to NVQ, I believe) and then when I did my degree in the UK (such a naive approach to think about classes as real world entities). But, if classes don’t correspond to physical entities, how do you organize them? And here is where they introduce the idea of roles and responsibilities, as the way to organize your code.

From that idea, it flows into the concept of Responsibility-Driven Design, which is just working on your design creating classes based on the roles and responsibilities that are needed to provide the functionality. Well, I say “just”, but it does require effort.

In the book Architecture Patterns with Python (which I will have to review at some point), Henry Percival and Bob Gregory say that DDD is just a special case of Responsibility-Driven Design.

Chapter 2 and Chapter 3 are heavy on non-code design exercises. I do believe that you want to have a very light planning around this kind of thinking (mostly I want to investigate rather than design before I start coding); I do like TDD; and I like that usage informs what I am building. But, the beauty of well thought-out ideas, like they present in the book, is that they can be used and still inform the way that you create your code in multiple ways. Even if you do TDD without any kind of initial planning, knowing the concepts introduced on this book will help you to create good systems.

From Chapter 5 onwards they work on considerations that you need to take into account when designing, like how object collaborate, how to make those collaborations reliable and the flexibility of your design (sometimes is needed, sometimes not, how much). And there are a lot of good insights there. I have used some of the ideas before in previous projects, when collaboration moves across teams and systems. Again, I am less interested in detailed non-code design when working within a team, I do prefer those discussions at the moment the code is written.

The End

Even when I knew most of the concepts given, this is a great book, and definitely one that should be read.