CSC/ECE 517 Fall 2007/wiki3 3 33

Topic - Separation of Responsibility (SoR)

Take the principle of Separation of Responsibility (abbreviated as SoR) 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.'

What is SoR

Separation of responsibility is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.

The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.

Some related concepts

SoR is closely related with other OO design principles, and hence we explore some related concepts below.

Object Oriented Programming: OO programming paradigm abstracts entities into class/object (an instance of a class) and their behaviors into methods. The target application is built based on these objects and their interactions. OO is a very good example to illustrate the concept of SoR. In OO paradigm, each class with its member variables and methods define an entity. Methods of this class can only be performed on objects belong to this class (with some exceptions like inheritance). Therefore, each class has a particular focus and defines a soft boundaries that separates its own states/behaviors from other classes.

Encapsulation: This refers to hiding implementation and other details of one class from others, exposing only interfaces to be invoked. The purpose of encapsulation is also related to SoR in that by concealing the internal operations of a class, clients who interact with it does not need to concern how the class is implemented, but instead just using it as a black box.

Information Hidding: "The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed." from (http://en.wikipedia.org/wiki/Information_hiding)

Abstraction: "Abstraction is the process of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose." from wiki(http://en.wikipedia.org/wiki/Abstraction)

Cohesion: "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed." from wiki(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)

Coupling: Coupling is usually contrasted with cohesion. Low coupling , more often than not, correlates with high cohesion, and tight coupling means low cohesion.

SoR categories by scope

Separation of Responsibility can be interpreted in both class level and software architecture level. Class level SoR requires a class or method focus on a single task or goal, not take up multiple responsibilities. Project/Software architecture level of SoR involves multi-tiered system which separates different system responsibilities to different tiers.

Class Level SoR

The website http://designparadigm.wordpress.com/ has a good example for separating multiple responsibilities within one method to multiple methods.

The following code is flawed in a SoR sense.

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);

}

In the above code, within the method it does three different things: create a user name, check the customer to see if it already registered and then save it.

The method name is createCustomer, but it does far more than creating a customer. As a matter of fact, this method should be refactored into 4 methods. The first method can be "bindValidateAndSave", which provides the algorithm. The 3 other methods can be named as "bindCustomer" (bind and add new shoppingCart), "validateCustomer"(validate the customer) and "saveCustomer" (save the customer). And thus separate different concerns to different methods.

Project/Architecture Level SoR

One of the most widely used web and GUI application design pattern - Model-View-Controller (MVC) - stands out as an zealous advocate for the "Separation of Responsibility" philosophy. We think it will be an excellent example to demonstrate the SoR concept in project/architecture level.

picture source: http://www.codeproject.com/useritems/PraticalMvc.asp

As above diagram illurstrated, MVC pattern separates the appliaction into three areas of responsibility to reduce the coupling between modules.

Model: This part is responsible for maintaining the state of the application. Most of the time, this part is related to the data of the system. Through some object relational mapping (ORM), model is used to create/read/update/delete (CRUD) data. What model needs to care is to realize these functionalities correctly and efficiently; it does not need to concern about who will use them, when and how they will be used. (in rare situations, code in model can be involving in other domain)
View: View's responsibility is rendered data, usually from data model, in the correct format and display it to client. This is its sole job. Code in view component does not care about how the backend data is stored, or what the business logic is, no matter how complex it may be.
Controller: Controller's job is receive user's input, performs defined computation, interacts with models, and invoke the appropriate view template to render the result to client.

As we can see, in MVC, code specialized in one category can always be easily found in a well-known location. Each category has its own focus and rarely overlap with others. By doing this, man power can be properly used: web graphic designer who knows HTML/CSS but not much about Java or C# may just focus on view category in MVC, and not worrying about the logic behind the application; programmers may focus on the logic and the correctness of the result, not have to concern about how it will be rendered to users. Database designers may focus on designing a efficient schema to be represented by data models, not anything more nor anything less. When later the application needs to be extended or changed, project manager can easily know who to talk to.

Ruby on Rails (RoR) is a web application development framework which is based on MVC design pattern. To see how Ruby on Rails uses MVC to achieve SoR, we will take a look at the following example:

Suppose we hava an online store which sells different products. Then we will most likely have a database table named "products" and a corresponding class wrapped about it. This class will go into our Model directory.

class CreateProducts <ActiveRecord::Migration
   def self.up
      creat_table :products do |t|
         t.column :title        :string
         t.column :descriprtion :text
      end
   end
   # ...rest of the code #
end

class Product < ActiveRecord::Base
   validates_presence_of :title, :description

   def self.find_products_for_sale
      find( :all, :order => "title" )
   end
end

RoR uses something called "migration" to define a DB table (CreateProducts in above example, for more detail description on RoR, refer to link below) and a matching model class that forms the Object-Relational Mapping (ORM) with it. Product class here is one of our model classes. We can see that the validation process of the data is done inside Prodcut class. In addtion, it reads data products ordered by their titles. The class dose not care how the products will be used or displayed, that is beyond its responsibility.

Now let's look at the 'View':

<h1>Products Listing</h1>
<% for product in @products %>
   <h3><%= h(product.title) %>
   <%= product.description %>
<% end %>

This is a .rhml RoR view template. We can see that is has some RoR code with standard html tags. This template iterate through the variable @products and display title and description of each element in it. Neither does it know nor should it care about which elements are in @products, which are not, how and why they are in it and so forth. Its only job is to render the content of them and nothing more. But we may question why and how, that's when controller comes into play:

class StoreController < ApplicationController
   @products = Product.find_products_for_sale
end

We can see controller here calls the model method, stores the result in a variable which the view template uses to display the result.

Through above example, we see clearly that RoR uses MVC to achieve SoR and its code is easy for other programmers to understand and follow.

In Summary

In sum, the elegance of code can be greatly enhanced by adhering to the separation of responsibility design principle. And it would also be highly desirable to implement SoR in software architecture level, which is evidenced by the MVC design pattern.