Object Role Stereotypes

In this article published in MSDN August, Jeremy Miller talked about Responsibility-Driven Design(RDD) and used some examples to demonstrate how we may apply RDD in designing objects.

RDD is closely related to CRC(Class/Responsiblity/Collaborator) card, a modeling tool for designing software. The RDD design principle starts with defining class's role in a program, list its responsibilities to fulfill the role and the interactions with other classes to accomplish it's responsibilities.

RDD categorizes 6 stereotypes in a program.

1. Information Holder: Knows things and provides information. May make calculations from the data that it holds.
2. Structurer: Knows the relationships between other objects.
3. Controller: Controls and directs the actions of other objects. Decides what other objects should do.
4. Coordinator: Reacts to events and relays the events to other objects.
5. Service Provider: Does a service for other objects upon request.
6. Interfacer: Objects that provide a means to communicate with other parts of the system, external systems or infrastructure, or end users.

Though I don't know RDD before, but it seems to me that these stereotypes have covered most of the objects in my programs. That is, I have been applying RDD tacitly in my programs already. For example, a data access object in my code is an Information Holder or a Structure. The facade pattern in my code is an interfacer. In my program, Controllers delegate requests from clients to Service Providers. An Event Handler in C# is equivalent to a Coordinator in RDD.

Good naming can be of great help when designing and maintaining software. RDD provides guidelines for me to group my objects. If a team has RDD in mind, it's easy to communicate software design among team members. If coders and maintainers share the same mindset, source code is pretty much self-documented. It's good to have such a tool in a programmer's toolbox.