CSC/ECE 517 Fall 2007/wiki3 3 qq

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.

Defination of Separation of Responsibility

In Object-Oriented Design (OOD)

• One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes.
• Different responsibilities should be divided among different objects. Ideally, each individual object has one single responsibility, which we call Single Responsibility Principle (SRP).

Why Separation of Responsibility

• Decreases the coupling between two classes. One class do not need to know the what happened in the other class and what kind of object the pointer points to. Let's think about a example shown below:

Each node consists of data and a link (next) and the LinkedList implemented from Nodes.

class Node { 
　　Object data; 
　　Node next; //point to next node 
　　} 
class Linklist implement Node{
    ...
    ...
}

• Don't Repeat Yourself

If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Don't repeat yourself is important if you want flexible and maintainable software.

• Once and Only Once

Each and every declaration of behavior should occur once, and only once. This is one of the main goals, if not the main goal, when refactoring code. The design goal is to eliminate duplicated declarations of behavior, typically by merging them or replacing multiple similar implementations with a unifying abstraction.

• Decreases the coupling between two classes. One class do not need to know the what happened in the other class and what kind of object the pointer points to.

Single Point of Truth Repetition leads to inconsistency and code that is subtly broken, because you changed only some repetitions when you needed to change all of them. Often, it also means that you haven't properly thought through the organization of your code. Any time you see duplicate code, that's a danger sign. Complexity is a cost; don't pay it twice. Although Curly's Law definitely applies to normalization and removing redundancies, Do One Thing is more nuanced than the various restatements of Do Each Thing Once outlined above. It runs deeper. Bob Martin refers to it as The Single Responsibility Principle:

The Single Responsibility Principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:

class Employee {

 public Money calculatePay()
 public void save()
 public String reportHours()

} This class violates the SRP because it has three reasons to change:

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