Fundamentals of Object-Oriented Design in UML: Book Review
One of my favourite recent blog posts is one written by Sammy Larbi on coupling and cohesion and while discussing it with Phil he suggested that I would probably like this book and in particular the chapter on connascence which I’ve previously written about.
Fundamentals of Object-Oriented Design in UML by Meilir Page-Jones
I really enjoyed reading this book and I think it’s one that I could come back and read again to gain something else from in the future.
Nearly all the mistakes that I’ve made and seen made with respect to the design of object oriented code are outlined in one form or the other in this book.
The book is split into three sections. The first discusses some fairly basic object oriented concepts, the second covers UML as a notation for describing our designs and the final section goes more deeply into the principles of object-oriented design.
This is something which Uncle Bob also touched on recently:
No. You still need all your design skills. You still need to know design principles, and design patterns. You should know UML. And, yes, you should create lightweight models of your proposed software designs.
We actually found on a project I worked on recently that everyone had a different way of diagramming a design and it would have been useful to have a common notation between us. UML is surely the tool to solve that problem.
An interrogative message is effectively a getter whereas the other two are commands being sent to the object. I’ve not seen the distinction between events which happened in the past and those which are going to happen in the immediate future.
The idea is that while some information about our object will be viewable to other objects e.g. through attributes/getters, we can still hide the implementation of that information internally so that if we we want to change it in the future then we won’t have to change all its clients too.
For example if we have a getter on an object to access a field then if other methods on that object want to access that field they should go via the getter instead of accessing the field directly.
I often find myself avoiding using getters with the hope that if don’t increase their usage then it will be easier to get rid of them in the future. This approach would discourage doing that.
The other part of this chapter describes ‘closed behaviour’ - all the operations on any class that we inherit from should obey our class’ invariant.
I think this can be where we go wrong when we write classes which extend a List for example. The API of a List will typically have ‘Add’ and ‘‘Remove’ operations but on a lot of the application I work on we only want the ‘Add’ functionality and not the ‘Remove’ option. Page Jones suggests that if we want to use inheritance in this situation then we should override methods on the super class to make ‘Remove’ do nothing.
I’m inclined to believe that we might be able to tell how related the features are by looking at the clients of the class and seeing whether they are all using the class in similar ways.
He then outlines three signs that we have cohesion problems with a class:
While reading the book I had the feeling that some of the ideas are quite similar to those in Domain Driven Design and since this book was published it contributes to my belief that a lot of DDD is covered by just doing OOP well.
Overall this is a really good book, worth reading.