CSC/ECE 517 Fall 2007/wiki3 3 qq

From Expertiza_Wiki
Revision as of 16:09, 17 November 2007 by GAGAMA (talk | contribs)
Jump to navigation Jump to search

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.[1]
  • 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

  • Reusability: Ready to be used in more than one application or environment.
  • Flexibility: An object with few responsibilities can be modified for use in applications or environments other than those for which it was specifically designed.
  • Maintainability: An object with few responsibilities can be easily modified to correct faults, improve performance, or other attributes, or adapt to a changed environment without affecting other functionality.[2]
  • Once and Only Once(The Dry Principle): The separation of responsibility can help to eliminate duplicated declarations of behavior, typically by merging them or replacing multiple similar implementations with a unifying abstraction.


A Example

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{
        ...
        ...
       public Object currentNode() 
    { 
          Node temp=cursor(); 
          return temp.data; 
      }
    }

Then, we make a object client responsible for traversing a list which and keeping track of where it is.

    class client{
        Linklist a   
    }






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

Reference

[1] [4] [2] [5]