Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T17:29:01Z

GAGAMA: /* Reference */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Separation of Responsibility. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
public void createCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return;
}
... //Check if a customer was already registered with that name
customer.setShoppingCart(new ShoppingCart());
customerService.save(customer);
...
}
</pre>

The above method name is save. So I expect that the code only does some saving. Instead, it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call ''bindValidateAndSave'' is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called ''validateCustomer'', ''bindCustomer'' (bind and add new shoppingCart),and ''saveCustomer'' respectively.[http://designparadigm.wordpress.com/] The code after using Separation of Responsibility is shown below:

<pre>
public void bindValidateAndSave(Map requestParameters) {
customer = validateCustomer(requestParameters);
bindCustomer(customer);
saveCustomer(customer);
}
</pre>
<pre>
public Customer validateCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
}
...
}
public void bindCustomer(Customer customer) {
customer.setShoppingCart(new ShoppingCart());
}
public void saveCustomer(Customer customer) {
customerService.save(customer);
}

</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

[5] http://www.zzrose.com/tech/pmr_sweEffectiveObjectResponsibility.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T17:27:43Z

GAGAMA: /* Example 2 */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T17:26:34Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Separation of Responsibility. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
...
}
</pre>

The above method name is save. So I expect that the code only does some saving. Instead, it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call ''bindValidateAndSave'' is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called ''validateCustomer'', ''bindCustomer'' (bind and add new shoppingCart),and ''saveCustomer'' respectively.[http://designparadigm.wordpress.com/] The code after using Separation of Responsibility is shown below:

<pre>
public void bindValidateAndSave(Map requestParameters) {
customer = validateCustomer(requestParameters);
bindCustomer(customer);
saveCustomer(customer);
}
public Customer validateCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
}
...
}
public void bindCustomer(Customer customer) {
customer.setShoppingCart(new ShoppingCart());
}
public void saveCustomer(Customer customer) {
customerService.save(customer);
}

</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T17:21:57Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Separation of Responsibility. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead, it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call ''bindValidateAndSave'' is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called ''validateCustomer'', ''bindCustomer'' (bind and add new shoppingCart),and ''saveCustomer'' respectively.[http://designparadigm.wordpress.com/] The code after using Separation of Responsibility is shown below:
<pre>
public void bindValidateAndSave(Map requestParameters) {
if (!validateCustomer(requestParameters))
return;
customer.setShoppingCart(new ShoppingCart());

}
public Customer validateCustomer(Map requestParameters) {
Customer customer = new Customer();
customer.setName = requestParameters.get("name");
if (customerService.getCustomerByName(customer.getName()) != null) {
System.out.println("Customer already exists");
return 0;
}
return 1;
}
public void bindCustomer(Customer customer) {
customer.setShoppingCart(new ShoppingCart());
}
public void saveCustomer(Customer customer) {
customerService.save(customer);
}

</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T17:02:48Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Separation of Responsibility. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead, it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call ''bindValidateAndSave'' is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called ''validateCustomer'', ''bindCustomer'' (bind and add new shoppingCart),and ''saveCustomer'' respectively.[http://designparadigm.wordpress.com/] The code after using Separation of Responsibility is shown below:
<pre>
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);
}
</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T17:02:12Z

GAGAMA:

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Separation of Responsibility. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead, it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call ''bindValidateAndSave'' is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called ''validateCustomer'', ''bindCustomer'' (bind and add new shoppingCart),and ''saveCustomer'' respectively.[http://designparadigm.wordpress.com/]

The code after using Separation of Responsibility is shown below:
<pre>
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);
}
</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:59:20Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call bindValidateAndSave is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called validateCustomer, bindCustomer (bind and add new shoppingCart),and saveCustomer respectively.

With the last method (saveCustomer) I get the WHY? question a lot, since the extracted method is actually only 1 line of code long. Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. In our example, if the saveNewCustomer 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. Instead now it defines the algorithm. In this case bind, validate, save. The implementation is just the save method. [http://designparadigm.wordpress.com/]

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:54:34Z

GAGAMA: /* Reference */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call bindValidateAndSave is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called bindCustomer (bind and add new shoppingCart), validateCustomer and saveCustomer.

With the last method (saveCustomer) I get the WHY? question a lot, since the extracted method is actually only 1 line of code long. Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. In our example, if the saveNewCustomer 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. Instead now it defines the algorithm. In this case bind, validate, save. The implementation is just the save method. [http://designparadigm.wordpress.com/]

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

[4] [http://designparadigm.wordpress.com/ Java by experience]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:54:00Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call bindValidateAndSave is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called bindCustomer (bind and add new shoppingCart), validateCustomer and saveCustomer.

With the last method (saveCustomer) I get the WHY? question a lot, since the extracted method is actually only 1 line of code long. Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. In our example, if the saveNewCustomer 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. Instead now it defines the algorithm. In this case bind, validate, save. The implementation is just the save method. [http://designparadigm.wordpress.com/]

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:52:50Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call bindValidateAndSave is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called bindCustomer (bind and add new shoppingCart), validateCustomer and saveCustomer.

With the last method (saveCustomer) I get the WHY? question a lot, since the extracted method is actually only 1 line of code long. Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. In our example, if the saveNewCustomer 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. Instead now it defines the algorithm. In this case bind, validate, save. The implementation is just the save method.

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:49:57Z

GAGAMA:

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>
The above method name is save. So I expect that the code only does some saving. Instead it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call bindValidateAndSave is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called bindCustomer (bind and add new shoppingCart), validateCustomer and saveCustomer.

With the last method (saveCustomer) I get the WHY? question a lot, since the extracted method is actually only 1 line of code long. Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. In our example, if the saveNewCustomer 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. Instead now it defines the algorithm. In this case bind, validate, save. The implementation is just the save method.

Working in this fashion takes some getting used to, but in the end I truly believe this produces stabler and more maintainable code.

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:48:28Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:48:05Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:47:51Z

GAGAMA: /* Example 2 */

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with another example. Consider following code:
<pre>
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);
}
</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:47:11Z

GAGAMA:

== 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 (SOR)==
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.[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc]
* 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 ==

*[[Encapsulation]]: Data are kept in only one place.

*[[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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[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.[3]

*[[Decreases the coupling between two objests]]: One class do not need to know what happened and implementation details in the other class (e.x.,what kind of object the pointer points to). [http://www.codinghorror.com/blog/archives/000805.html]

== Applications of Separation of Responsibility ==
=== An Example Not using SOR===
I am thinking maybe it is better for us to first take a look at what is NOT an Single Responsibility Principle. The SOR principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>
This class violates the SOR 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.
Obviously, 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.

=== Example 2 ===
Let’s look into the matter with an example. Consider following code:
<pre>
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);}
</pre>

=== Example 3===
Let's think about a example shown below:
Each ''node'' consists of data and a link (next) and the ''LinkedList'' implemented from Nodes.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

== Reference ==
[1] http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.doc

[2] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us Programming Life and the Zen of Computers]

[3] http://www.codinghorror.com/blog/archives/000805.html

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:34:39Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:33:44Z

GAGAMA: /* An Example Not using SOR */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:33:05Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:30:38Z

GAGAMA: /* An Example - NOT using SOR */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:30:17Z

GAGAMA: /* Defination of Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:29:58Z

GAGAMA: /* An Example - NOT Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:27:49Z

GAGAMA: /* An Example - NOT Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:25:28Z

GAGAMA: /* Applications of Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:17:57Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:17:15Z

GAGAMA: /* Reference */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:17:07Z

GAGAMA: /* Reference */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:16:43Z

GAGAMA: /* Reference */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:16:29Z

GAGAMA: /* Reference */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:14:58Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:13:07Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:12:23Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:11:58Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:11:05Z

GAGAMA: /* Application of Separation of */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:10:43Z

GAGAMA: /* A Example */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:09:53Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:09:16Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:08:12Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:04:42Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T16:03:32Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:59:40Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:58:59Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:58:24Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:55:45Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:52:59Z

GAGAMA:

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:52:27Z

GAGAMA: /* Defination of Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:51:58Z

GAGAMA: /* Defination of Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:51:08Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:46:32Z

GAGAMA: /* Why Separation of Responsibility */

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:44:46Z

GAGAMA:

== 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 ==

*[[Flexibility]]: A object with few responsibilities can be modified for use in applications or environments other than those for which it was specifically designed. [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[Maintainability]]: A 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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[Reusability]]: The degree to which a software module or other work product can be used in more than one computing program or software system.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*Scalability: The ease with which a system or component can adjust to changing load.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

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

*Avoid code repetition
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.

=== 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.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

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] [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

CSC/ECE 517 Fall 2007/wiki3 3 qq

2007-11-17T15:42:52Z

GAGAMA: /* Why Separation of Responsibility */

== 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 ==

*[[Flexibility]]: A object with few responsibilities can be modified for use in applications or environments other than those for which it was specifically designed. [http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[Maintainability]]: A 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.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*[[Reusability]]: The degree to which a software module or other work product can be used in more than one computing program or software system.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

*Scalability: The ease with which a system or component can adjust to changing load.[http://64.233.169.104/search?q=cache:hv11-bOg9tAJ:www.hanselman.com/blog/PermaLink.aspx%3Fguid%3Da0a65e0c-5ef8-41e4-a566-1739b4428aa5+Separation+of+Responsibility+programming&hl=en&ct=clnk&cd=32&gl=us]

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

*Avoid code repetition
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.

=== 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.
<pre>
class Node {
　　 Object data;
　　 Node next; //point to next node
　　 }

class Linklist implement Node{
...
...
public Object currentNode()
　　　　{
　　 Node temp=cursor();
　　 return temp.data;
　　 }
}
</pre>
Then, we make a object ''client'' responsible for traversing a list which and keeping track of where it is.
<pre>
class client{
Linklist a
}

</pre>

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