Roles in Responsibility-Driven Design

You might be familiar with responsibility, it is present in our daily work & day-to-day life. For software development is no exception. When writing every piece of code, think about what you’re doing. Responsibility-Driven Design (RDD) is a technique in object-oriented programming, which improves encapsulation by using the client–server model. Today we have a look at RDD role stereotypes.

What is Responsibility-Driven Design (RDD)?

The concept was conceived back in 1990 as a shift from thinking about objects as data and algorithms, to thinking about roles and responsibilities. Rebecca Wirfs-Brock, object design pioneer who invented the set of design practices known as Responsibility-driven design defines it as “a way to design software that… –emphasizes modeling of objects’ roles, responsibilities, and collaborations –uses informal tools and techniques –adds responsibility concepts and thinking to any process”.  

According to Rebecca Wirfs-Brock, RDD have 3 main principles:

1. Maximize Abstraction
2. Distribute Behaviour
3. Preserve Flexibility Design

In contrast to Data-Driven Design, Responsibility-Driven Design focuses on the contract by considering the actions that the object is responsible for and the information that the object shares and tries to avoid dealing with details, delegating control to assign responsibilities to elements and therefore each element would be reused very quickly. 

Design Terms in RDD

First, let’s have a look at the common terminology when talking about Responsibility-Driven Design.

• Application: set of interacting objects.
• Object: implementation of one or more roles.
• Role: set of related responsibilities.
• Responsibility: obligation to perform a task or know information.
• Collaboration: interaction of objects or roles (or both).
• Contract: agreement outlining the terms of a collaboration.

Objects should have a specific purpose to play within a software system. Meanwhile roles can be implemented using interfaces and composition. Today we analyze some role stereotypes that have proven useful over time.

Role Stereotypes in RDD

Defining responsibilities is crucial to have a good software design. Rebecca Wirfs-Brock describes some roles to describe different types of responsible implementations to help you define software elements. 

A single responsibility is larger than an operation or attribute. When defining classes, the Single Responsibility Principle comes in mind. Each class should do only one task/responsibility but how do we state responsibilities? Here is where role stereotypes are useful.

Let’s explore role stereotype categories:

• Controller: makes decisions and closely directs the action of other objects.
• Coordinator: reacts to events by delegating tasks to others.
• Information Holder: knows and provides information.
  • Information Provider: A slight variation of an information holder which takes a more active role in managing and maintaining information.
• Interfacer: transforms information and requests between distinct parts of an application.
  • External Interfacer: communicates with other applications rather than its own.
  • Internal Interfacer: act as a bridge between object neighborhoods.
  • User Interfacer: communicates with users by responding to events generated in the UI and then passing them on to more appropriate objects.
• Service Provider: performs work and offers computing services.
• Structurer: maintains relationships between objects and information about those relationships.

If you want to learn more about Responsibility-Driven Design, A Brief Tour of Responsibility-Driven Design by Rebecca Wirfs-Brooks is definitely worth reading. Rebecca Wirfs-Brooks will be one of the speakers invited to the next edition of the Global Software Architecture Summit (GSAS) organized by Apiumhub.