For a while we started to do design sessions. Nothing fancy but if you did not do it before is not trivial, try it. And to be more clear by this, I mean : you know what the product owner wants, now you want with your team to come up with a design which will solve the problem.
Where do I start?
Decompose the problem into small parts and tackle them in isolation. This what you will find everywhere. But how will I apply this in my situation ? How I can find the right granularity ? Where do I start my design ? With what?
Right here
If I could know thins before reading Object Design, Roles, Responsibilities and Collaborations, a lot of things were different. If you have read this book skip this article if not keep going. How ?
Starting with:
- Application = a set of interacting objects
- Object = an implementation of one or more roles
- Role = a set of related responsibilities
- Responsibility = an obligation to know information or perform a task
- Collaboration = an interaction of roles or objects
- Contract = an agreement of outlining the terms of collaboration
In this big machinery every objects has a purpose, a role to play in the specific context. If two objects play the same role they can be interchanged.
Role Stereotypes – help to focus on object’s responsibilities. A well defined object supports a clearly defined role. Because the goal is to build consistent and easy to use objects it’s advantageous to stereotype them ignoring specifics of behavior and thinking at a higher level.
Stereotyping - design gets descriptive:
- Information holder – knows and provides information
- Structurer maintains relations between objects and information about the relations
- Service provider – does work, or offers computing services
- Coordinator – reacts to events by delegating tasks to others
- Controller – makes decisions and directs commands
- Interfacer – transforms information and requests between distinct parts of the system
One object can play more than one role in the given context and that is ok if just one role is considered major. If one object is used in 2 contexts for different purposes then the object pays 2 distinct roles and it clearly violates single responsibility principle.
Conclusion
Design using role stereotypes the following system: a building 50 levels has 2 elevators, one is at 47 coming down, another is at 1st going to 9th floor. You just went out of your apartment, al level 11 and intend to visit your friend at 32th.
Once you are done with this try to do the old way and compare them
Stereotyping gave us the clear vision of – Single Responsibility Principle. Objects became smaller with descriptive names. Testing for simple objects is a breeze, code easy to change and ready for new functionality. Overall – confidence and predictability.
comments powered by Disqus