Book Club: Object Role Stereotypes (Jeremy Miller)
In last week’s book club we discussed an article written by Jeremy Miller for MSDN Magazine titled ‘Object Role Stereotypes’ which discusses part of Rebecca Wirfs Brock’s book ‘Object Design’.
I’ve been trying to read Object Design for about a year since coming across the book while reading through the slides from JAOO Sydney 2008 but I’ve often found the reading to be quite abstract and have struggled to work out how to apply the ideas to the coding I do day to day.
This therefore seemed to be like a good opportunity to get some more opinions and discussion on at least part of the book.
There are some of my thoughts and our discussion of the article:
- Liz pointed out that at ThoughtWorks University (which we both attended) we were shown the idea of writing the 'job' of an object just above the class definition, the point of this being that we would describe the responsibility of the object and ensure that objects only had one responsibility. Neither Liz nor I have ever seen this done on any of the projects that we've worked on but it seems quite related to the idea of responsibility driven development which is encouraged in the book. The different role stereotypes would form part of the responsibilities that an object might have. Matt Dunn suggested that perhaps the tests we write fulfill this role instead in a more indirect way although I think we would probably need to be writing tests with the quality Jimmy Bogard describes in his post on getting value our of your unit tests, instead of the pale imitations we often end up writing, to achieve this goal.
- I find each of the individual stereotypes quite difficult to remember on their own but Jeremy pointed out that they fit into 3 categories:
- Knowing (Information Holder, Structurer)
- Doing (Service Provider, Interfacer)
- Deciding (Controller, Coordinator)
I think the object role stereotypes mix quite nicely with some of the ideas from Domain Driven Design - for example a value object would probably be an information holder; an entity might be a structurer and an information holder; a factory could be a service provider; a repository is possibly an interfacer although I think that may be more the case if we are using a repository as a DAO instead of a true DDD repository.
- I think it might actually be easier when looking at existing code to question whether or not a particular object is actually only doing one thing or not before analysing which of the stereotypes it is fulfilling. We discussed although didn’t come to a conclusion whether there are certain stereotypes that should not be mixed together in one object. For example maybe an object which acts as an interfacer wouldn’t store state and therefore might not be an information holder as well.
- We briefly discussed some other articles which cover similar ideas including Isaiah Perumalla’s article on role based objects and Udi Dahan’s idea of the roles being described more specifically in the interface name. Both of these articles have some good ideas and I find the latter particularly intriguing although I haven’t tried it out on any code I’ve written as yet.
- The article also has some great ideas around coding in general which I think make a lot of sense:
Don't be afraid to create small objects instead of wallowing in the mud of primitive variables
Designing software is often an exercise in managing complexity…you can take steps to limit the complexity of any given class by only assigning it a discrete set of responsibilities