CSC/ECE 517 Fall 2007/wiki3 3 ab

Topic

Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.

Introduction

Separation of Responsibility

In Object-Oriented Design (OOD), Separation of Concern is well known as a principle or process of breaking computer program codes into different components that have little coupling with each other and have strong cohesion. Following this principle, a class should have one clearly defined responsibility. In separation of concern, there are two important concepts: Separation of Responsibility and Separation of knowledge (information and environment hiding).

Separation of responsibility states that specific functionality or specific actions are assigned to design components and are not distributed throughout a design [3], in another word, each individual object should have as few responsibilities as possible, ideally one responsibility per object.

Why to use separation of responsibility

Before we discuss the separation of responsibility, let us have a look at the following class:

class Employee
{
  public Money calculatePay()
  public void save()
  public String reportHours()
}

This class have to be changed when the following aspects are changed.

• The business rules having to do with calculating pay.
• The database schema.
• The format of the string that reports hours.

We don't want a single class to be impacted by these three completely different forces. We don't want to modify the Employee class every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation. Rather, we want to separate these functions out into different classes so that they can change independently of each other.

It is easy to maintain and change the program that follows separation of responsibility.

Principle of Separation of Responsibility

There are several principles of Separation of Responsibility [1]:

• Single Responsibility Principle (SRP). Different responsibilities should be divided among different objects, in another word, one object should have only one responsibility in ideal situation. We can only say A class should have only one reason to change. We want to focus classes, functions, etc. so that there is only one reason for them to change. This is why many people separate their application into layers. For example, The data access layer provides persistence and re-hydration of business objects. The business layer is all about business rules. And, the presentation layer is only about presenting information to the user. Hopefully a change in one layer won't cause a ripple effect of changes in other layers, or at least, keep the impact to a minimum.[8]
• Encapsulation. One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.
• Expert pattern. The object that contains the necessary data to perform a task should be the object that manipulates the data.
• The Dry principle. Code should not be duplicated. A given functionality should be implemented only in one place in the system.

Examples

Java Example for Principle of Separation of Responsibility

There is an Java example of principle of Separation of responsibility[4].

public void createCustomer(Map requestParameters) {
	Customer customer = new Customer();
	customer.setName = requestParameters.get("name");

	//Check if a customer was already registered with that name
	if (customerService.getCustomerByName(customer.getName()) != null) {
		System.out.println("Customer already exists");
		return;
	}
	customer.setShoppingCart(new ShoppingCart());

	customerService.save(customer);
}

The method name is create. While others viewing the the code will expect to have a create function. But instead it has three functionality, creates a customer, checks if it's already exist and then save it. It should divide these functionality into 4 methods.

1. bindValidateAndSave The application method. It tells what to do rather than how's done.
2. bindCustomer bind and add new shoppingCart.
3. validateCustomer validate if customer exist.
4. saveCustomer save customer

The last method saveCustomer has only 1 line of code, why were we let it become a individual method? Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. Because it calls customerService.save(). it’s responsible that the save method is actually called right. Instead if we let it delegate to a newly extracted method (saveCustomer) it isn’t responsible for the explicit saving.

Example for Information Expert(Expert pattern)

There is a simple part of a POS system example[9].

We make choices about the assignment of responsibilities to classes. Information Expert helps us decide, once we know the task (responsibility), which class to make responsible for carrying out the task.

Assign a responsibility to the information expert; the class that has the information necessary to fulfill the responsibility. So after we apply the expert pattern to the example above, it become following diagram.

Reference

1. Elegance and classes
2. Separation of concerns
3. A Logical Theory of Interfaces and Objects
4. Java by Experience
5. OO Programming By Example
6. TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling
7. Benefits of the Three-Tiered Architecture
8. Single-Responsibility Principle
9. Information Expert
10. [1]
11. [2]
12. [3]