Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-28T20:20:30Z

Kstsai: /* Principle of 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

There are several principles of Separation of Responsibility [1]:
* '''Single Responsibility Principle (SRP)'''. Different responsibilities should be divided among different objects. In another word, one object should have only one responsibility in ideal situation. We can only say '''A class should have only one reason to change.''' We want to focus classes, functions, etc. so that there is only one reason for them to change. This is why many people separate their application into layers. For example, Ruby on Rails has three layers, View, Model and Controller. Different layers handle different rules. When we change database, we only need to change models. And when we change business logics, we only need to change Controllers.
* '''Encapsulation'''. One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In other word, Data should be kept in only one place.
* '''Expert pattern'''. The object that contains the necessary data to perform a task should be the object that manipulates the data.
* '''The Dry principle'''. Code should not be duplicated. A given functionality should be implemented only in one place in the system.

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

<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 method name is ''create''. While others viewing the the code will expect to have a create function. But instead it has three functionalities, creates a customer, checks if it's already exist and then save it. It should divide these functionalities into 4 methods.

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

The last method ''saveCustomer'' has only 1 line of code, why were we let it become a individual method? It is show how it works although it might not improve the readability of the code.

Each methods only doing one thing and have only one responsibility. The blind, validate and save separately in different methods.

===Example for Single Responsibility Principle(SRP)===

Single responsibility principle is to say that an object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have an object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsibilities, having only one responsibility for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understood.

===Example for Encapsulation principle===

One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.

For example:
<pre>
public class Person {

private String firstName;
private String lastName;
private String suffixName;

public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
</pre>

In this example, class ''Person'' is responsible for the data ''firstName'', ''lastName'', ''suffixName''. ''Person'' uses methods ''getFirstName'' and ''setFirstName'' to get or set data. Other classes that need to use these data have to call these methods of objects declared as ''Person'', they can not use or modify these data directly.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html OOD - Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-28T20:19:36Z

Kstsai: /* Principle of 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

There are several principles of Separation of Responsibility [1]:
* '''Single Responsibility Principle (SRP)'''. Different responsibilities should be divided among different objects. In another word, one object should have only one responsibility in ideal situation. We can only say '''A class should have only one reason to change.''' We want to focus classes, functions, etc. so that there is only one reason for them to change. This is why many people separate their application into layers. For example, Ruby on Rails has three layers, View, Model and Controller. Different layers handle different rules. When we change database, we only need to change models. And when we change business logics, we only need to change Controllers.
* '''Encapsulation'''. One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.
* '''Expert pattern'''. The object that contains the necessary data to perform a task should be the object that manipulates the data.
* '''The Dry principle'''. Code should not be duplicated. A given functionality should be implemented only in one place in the system.

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

<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 method name is ''create''. While others viewing the the code will expect to have a create function. But instead it has three functionalities, creates a customer, checks if it's already exist and then save it. It should divide these functionalities into 4 methods.

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

The last method ''saveCustomer'' has only 1 line of code, why were we let it become a individual method? It is show how it works although it might not improve the readability of the code.

Each methods only doing one thing and have only one responsibility. The blind, validate and save separately in different methods.

===Example for Single Responsibility Principle(SRP)===

Single responsibility principle is to say that an object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have an object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsibilities, having only one responsibility for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understood.

===Example for Encapsulation principle===

One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.

For example:
<pre>
public class Person {

private String firstName;
private String lastName;
private String suffixName;

public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
</pre>

In this example, class ''Person'' is responsible for the data ''firstName'', ''lastName'', ''suffixName''. ''Person'' uses methods ''getFirstName'' and ''setFirstName'' to get or set data. Other classes that need to use these data have to call these methods of objects declared as ''Person'', they can not use or modify these data directly.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html OOD - Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-28T20:12:36Z

Kstsai: /* Java Example for Principle of 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

<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 method name is ''create''. While others viewing the the code will expect to have a create function. But instead it has three functionalities, creates a customer, checks if it's already exist and then save it. It should divide these functionalities into 4 methods.

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

The last method ''saveCustomer'' has only 1 line of code, why were we let it become a individual method? It is show how it works although it might not improve the readability of the code.

Each methods only doing one thing and have only one responsibility. The blind, validate and save separately in different methods.

===Example for Single Responsibility Principle(SRP)===

Single responsibility principle is to say that an object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have an object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsibilities, having only one responsibility for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understood.

===Example for Encapsulation principle===

One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.

For example:
<pre>
public class Person {

private String firstName;
private String lastName;
private String suffixName;

public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
</pre>

In this example, class ''Person'' is responsible for the data ''firstName'', ''lastName'', ''suffixName''. ''Person'' uses methods ''getFirstName'' and ''setFirstName'' to get or set data. Other classes that need to use these data have to call these methods of objects declared as ''Person'', they can not use or modify these data directly.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html OOD - Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-28T20:08:40Z

Kstsai: /* Java Example for Principle of 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

<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 method name is ''create''. While others viewing the the code will expect to have a create function. But instead it has three functionalities, creates a customer, checks if it's already exist and then save it. It should divide these functionalities into 4 methods.

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

The last method ''saveCustomer'' has only 1 line of code, why were we let it become a individual method? It is show how it works although it might not improve the readability of the code.

===Example for Single Responsibility Principle(SRP)===

Single responsibility principle is to say that an object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have an object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsibilities, having only one responsibility for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understood.

===Example for Encapsulation principle===

One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.

For example:
<pre>
public class Person {

private String firstName;
private String lastName;
private String suffixName;

public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
</pre>

In this example, class ''Person'' is responsible for the data ''firstName'', ''lastName'', ''suffixName''. ''Person'' uses methods ''getFirstName'' and ''setFirstName'' to get or set data. Other classes that need to use these data have to call these methods of objects declared as ''Person'', they can not use or modify these data directly.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html OOD - Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T21:34:56Z

Kstsai: /* Example for Single Responsibility Principle(SRP) */

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

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

<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 method name is ''create''. While others viewing the the code will expect to have a create function. But instead it has three functionalities, creates a customer, checks if it's already exist and then save it. It should divide these functionalities into 4 methods.

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

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

===Example for Single Responsibility Principle(SRP)===

Single responsibility principle is to say that an object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have an object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsibilities, having only one responsibility for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understood.

===Example for Encapsulation principle===

One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.

For example:
<pre>
public class Person {

private String firstName;
private String lastName;
private String suffixName;

public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
</pre>

In this example, class ''Person'' is responsible for the data ''firstName'', ''lastName'', ''suffixName''. ''Person'' uses methods ''getFirstName'' and ''setFirstName'' to get or set data. Other classes that need to use these data have to call these methods of objects declared as ''Person'', they can not use or modify these data directly.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T21:34:43Z

Kstsai: /* References */

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

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

<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 method name is ''create''. While others viewing the the code will expect to have a create function. But instead it has three functionalities, creates a customer, checks if it's already exist and then save it. It should divide these functionalities into 4 methods.

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

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

===Example for Single Responsibility Principle(SRP)===

Single responsibility principle is to say that an object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[11]

We have an object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsibilities, having only one responsibility for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understood.

===Example for Encapsulation principle===

One class should be responsible for knowing and maintaining a set of data, even if that data is used by many other classes. In another word, Data should be kept in only one place.

For example:
<pre>
public class Person {

private String firstName;
private String lastName;
private String suffixName;

public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
</pre>

In this example, class ''Person'' is responsible for the data ''firstName'', ''lastName'', ''suffixName''. ''Person'' uses methods ''getFirstName'' and ''setFirstName'' to get or set data. Other classes that need to use these data have to call these methods of objects declared as ''Person'', they can not use or modify these data directly.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:51:15Z

Kstsai: /* Example for Information Expert(Expert pattern) */

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

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[11]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:46:40Z

Kstsai: /* 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[11]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==References==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:43:31Z

Kstsai: /* Example for Single Responsibility Principle(SRP) */

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

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[11]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==Reference==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:43:18Z

Kstsai: /* Principle of 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==Reference==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:43:00Z

Kstsai: /* Example for Information Expert(Expert pattern) */

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

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==Reference==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:42:17Z

Kstsai: /* 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==Reference==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html Single Responsibility Principle]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:41:45Z

Kstsai: /* Example for Single Responsibility Principle(SRP) */

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

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.[10]

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==Reference==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:41:12Z

Kstsai: /* 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. ''

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

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

===Why using separation of responsibility===

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

<pre>
class Employee
{
public Money calculatePay()
public void save()
public String reportHours()
}
</pre>

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

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

That is to say, the class ''Employee'' is impacted by three completely different responsibilities. Every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation, we have to change the class ''Employee''.

Separation of responsibility can avoid this trouble. When using separation of responsibility, these three functions ''calculatePay()'', ''save()'', ''reportHours()'' will be separated into different classes so that they can change independently without influence others. Using separation of responsibility, programs are easy to maintain and change.

===Principle of Separation of Responsibility===

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

==Examples==

===Java Example for Principle of Separation of Responsibility===

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

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

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

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

Single responsibility principle is to say that a object should only has one reason to change. If there are more than one reason to change the object then we should split the object into smaller object which has one responsibility.

We have a object to keep an email message as below.

<pre>
// single responsability principle - bad example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
</pre>

The IEmail interface has two responsibilities.
*One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols.
*Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

We can create a new interface and class called IContent and Content to split the responsabilities. Having only one responsability for each class give us a more flexible design.

*adding a new protocol causes changes only in the Email class.

*adding a new type of content supported causes changes only in Content class.

<pre>
// single responsability principle - good example

interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}

interface Content {
public String getAsString(); // used for serialization
}

class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
</pre>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of Responsibility is done only when the full picture of how the application should work is well understand.

===Example for Information Expert(Expert pattern)===

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

[[Image:Topic14NotesImage1.jpg]]

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

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

[[Image:Topic14NotesImage2.jpg]]

==Reference==
#[http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf Elegance and classes]
#[http://en.wikipedia.org/wiki/Separation_of_concerns Separation of concerns]
#[http://ieeexplore.ieee.org/iel5/32/21774/01010059.pdf?arnumber=1010059 A Logical Theory of Interfaces and Objects]
#[http://www.codinghorror.com/blog/archives/000805.html Curly's Law: Do One Thing]
#[http://designparadigm.wordpress.com/ Java by Experience]
#[http://www.codeproject.com/vb/net/OOPbyExample.asp OO Programming By Example]
#[http://codebetter.com/blogs/jeremy.miller/pages/129542.aspx TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling]
#[http://www.babysentry.com/tech_specs_benefits.htm Benefits of the Three-Tiered Architecture]
#[http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx Single-Responsibility Principle]
#[http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/InformationExpert.html Information Expert]
#[http://www.oodesign.com/oo_principles/oo_principles/single_responsibility_principle.html]

CSC/ECE 517 Fall 2007/wiki3 3 ab

2007-11-17T20:39:49Z

Kstsai: /* Example for Single Responsibility Principle(SRP) */

Kstsai: /* Topic */

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-30T01:56:44Z

Kstsai: /* Exercise for Teaching in a Class */

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book: the information about the book, include title, author, register code...etc.
*Librarian: the role who manage books.
*Borrower: the one borrow books include their contact.
*Date: to record which day the book been borrow and return.
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

To let the activities approach, this paper has some suggestions.
*Carefully distinguish between classes and objects.
*Make scenarios as specif as possible.
*Start with the simplest possible meaningful scenario.
*Initialize the role-play properly.
*Be careful with object names.

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:

[[Image:crcCardStudent.jpg]]

How to create CRC model? just follow these steps:

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.
and then with the small increment you are able to do more practices to learn more about CRC cards. You can create a single requirement such as user story, business rule, or system use case, instead of the entire collection of requirements for your system.

I think this is an easy example for student to self-study. This the example here is related to student experience. Compare to other examples, some are hard for student to understand and some are too complicated. This one with simple case and short description will help student to learn the general idea of CRC cards.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-30T01:56:14Z

Kstsai:

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book: the information about the book, include title, author, register code...etc.
*Librarian: the role who manage books.
*Borrower: the one borrow books include their contact.
*Date: to record which day the book been borrow and return.
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

To let the activities approach, this paper has some suggestions.
*Carefully distinguish between classes and objects.
*Make scenarios as speci�c as possible.
*Start with the simplest possible meaningful scenario.
*Initialize the role-play properly.
*Be careful with object names.

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:

[[Image:crcCardStudent.jpg]]

How to create CRC model? just follow these steps:

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.
and then with the small increment you are able to do more practices to learn more about CRC cards. You can create a single requirement such as user story, business rule, or system use case, instead of the entire collection of requirements for your system.

I think this is an easy example for student to self-study. This the example here is related to student experience. Compare to other examples, some are hard for student to understand and some are too complicated. This one with simple case and short description will help student to learn the general idea of CRC cards.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-30T01:54:51Z

Kstsai: /* Exercise for Teaching in a Class */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book: the information about the book, include title, author, register code...etc.
*Librarian: the role who manage books.
*Borrower: the one borrow books include their contact.
*Date: to record which day the book been borrow and return.
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

To let the activities approach, this paper has some suggestions.
*Carefully distinguish between classes and objects.
*Make scenarios as speci�c as possible.
*Start with the simplest possible meaningful scenario.
*Initialize the role-play properly.
*Be careful with object names.

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:

[[Image:crcCardStudent.jpg]]

How to create CRC model? just follow these steps:

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.
and then with the small increment you are able to do more practices to learn more about CRC cards. You can create a single requirement such as user story, business rule, or system use case, instead of the entire collection of requirements for your system.

I think this is an easy example for student to self-study. This the example here is related to student experience. Compare to other examples, some are hard for student to understand and some are too complicated. This one with simple case and short description will help student to learn the general idea of CRC cards.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-30T01:46:45Z

Kstsai: /* Exercise for Self-study */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book: the information about the book, include title, author, register code...etc.
*Librarian: the role who manage books.
*Borrower: the one borrow books include their contact.
*Date: to record which day the book been borrow and return.
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:

[[Image:crcCardStudent.jpg]]

How to create CRC model? just follow these steps:

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.
and then with the small increment you are able to do more practices to learn more about CRC cards. You can create a single requirement such as user story, business rule, or system use case, instead of the entire collection of requirements for your system.

I think this is an easy example for student to self-study. This the example here is related to student experience. Compare to other examples, some are hard for student to understand and some are too complicated. This one with simple case and short description will help student to learn the general idea of CRC cards.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-25T01:59:20Z

Kstsai: /* Exercise for Teaching in a Class */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book: the information about the book, include title, author, register code...etc.
*Librarian: the role who manage books.
*Borrower: the one borrow books include their contact.
*Date: to record which day the book been borrow and return.
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:

[[Image:crcCardStudent.jpg]]

How to create CRC model? just follow these steps:

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.

Why I think this is a good web site for self study? The example here is easy and close to student’s experience, therefore student can understand easily without others help.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-25T01:55:40Z

Kstsai: /* Exercise for Self-study */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book
*Librarian
*Borrower
*Date
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:

[[Image:crcCardStudent.jpg]]

How to create CRC model? just follow these steps:

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.

Why I think this is a good web site for self study? The example here is easy and close to student’s experience, therefore student can understand easily without others help.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

File:CrcCardStudent.jpg

2007-10-25T01:53:06Z

Kstsai:

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-25T01:52:49Z

Kstsai: /* Exercise for Self-study */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book
*Librarian
*Borrower
*Date
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.
Here's the example of one of the CRC card look like:
[[Image:crcCardStudent.jpg]]

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.

Why I think this is a good web site for self study? The example here is easy and close to student’s experience, therefore student can understand easily without others help.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-25T01:49:04Z

Kstsai: /* Exercise for Teaching in a Class */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book
*Librarian
*Borrower
*Date
[[Image:Library diagram.JPG]]

Each student play a role to discuss with others.

[[Image:roles.JPG]]

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.
Why I think this is a good web site for self study? The example here is easy and close to student’s experience, therefore student can understand easily without others help.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]

File:Roles.JPG

2007-10-25T01:48:05Z

Kstsai:

CSC/ECE 517 Fall 2007/wiki2 5 kq

2007-10-25T01:47:37Z

Kstsai: /* Exercise for Teaching in a Class */

'''This Wiki Page is edited by Kunta Tsai and Qinyi Ding'''

=Topic=
''CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?''

=Definition=
A Class Responsibility Collaborator (CRC) model ([http://c2.com/doc/oopsla89/paper.html#cards Beck & Cunningham] 1989; Wilkinson 1995; [http://www.ambysoft.com/books/theObjectPrimer.html Ambler] 1995) is a collection of standard [http://en.wikipedia.org/wiki/Index_card index cards] that are used when first determining which [http://en.wikipedia.org/wiki/Class_%28computer_science%29 classes] are needed and how they will interact.
A CRC card always contain these sections:
* The class name: represents a collection of similar objects
* Its Super and Sub classes (if applicable)
* The responsibilities of the class: represents something a class knows or does
* The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
* Author

An example of CRC card is shown in figure 1.

Figure 1:

[[Image:CRCCard.gif]]

=Advantages of CRC Card=
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

=Best Page Related to CRC ---- Example of ATM Machine=
[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html CRC Cards for ATM Example] is a very good page for a CRC card instantiation. We have browsed through hundreds of websites regarding to CRC card, and this page offers a clearest and most complete example using CRC card and Java implementation.

The example the page provides is how to design an [http://en.wikipedia.org/wiki/Automated_teller_machine ATM machine]. It is absolutely not an easy task since an ATM machine has to interact with the bank and the user, and a transaction is also related to reading card and printing receipt. Moreover, the login system is essential to ensure security. In order to deal with the relationship of so many distinct classes of objects, we need the help of CRC card.

The description on the CRC card of each class makes it clear of the responsibility and collaborate class of the specific class, and facilitate the designer to design interfaces more easily.

Below is a complete list of the class used in an ATM machine design. You can click the link to access to the corresponding CRC card.
*[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ATM Class ATM]

<table width = 60%><tr><td>Boundary/entity objects</td><td>Controller objects</td><td>Entity objects</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CardReader Class CardReader]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Session Class Session]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Balances Class Balances]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CashDispenser Class CashDispenser]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transaction Class Transaction]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Card Class Card]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#CustomerConsole Class CustomerConsole]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Withdrawal Class Withdrawal]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Message Class Message]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#EnvelopeAcceptor Class EnvelopeAcceptor]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Deposit Class Deposit]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Receipt Class Receipt]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Log Class Log]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Transfer Class Transfer]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Status Class Status]</td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#NetworkToBank Class NetworkToBank]</td><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#Inquiry Class Inquiry]</td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#OperatorPanel Class OperatorPanel]</td><td></td><td></td></tr>
<tr><td>[http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/CRCCards.html#ReceiptPrinter Class ReceiptPrinter]</td><td></td><td></td></tr>
</table>

There are many other websites which introduce the concept and examples of CRC card. Please refer to the [http://pg.ece.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_kq#Reference Reference] of this page if you are interested.

=Examples of CRC=
Since CRC card is a kind of conceptual description of classes, it uses more natual language than programming language like Java and Ruby. There are few websites which introduce the implementation of CRC card using Java, and fewer using Ruby. Let's take a look at a brief example from our best CRC page.

A card reader is important to an ATM machine. The card reader is the interface to connect ATM and the card. It should tell ATM when a card is inserted, and should be able to read the information in the card. To eject card and retain card are also key functions of a card reader.
Therefore, the CRC card of a card reader could look like:

[[Image:CRCCardReader.JPG]]

The UML diagram of the class is:

[[Image:CardReader.JPG]]

Hence the card reader class should have:
*Variables:
atm: The ATM to which this card reader belongs

*Constructor:
CardReader(ATM): Constructor

*Methods:
ejectCard() : Eject the card that is currently inside the reader.
readCard() : Read a card that has been partially inserted into the reader
retainCard(): Retain the card that is currently inside the reader for action by the bank.
----
From the design above, we can easily code the class as:
<pre>
/*
* ATM Example system - file CardReader.java
*
* copyright (c) 2001 - Russell C. Bjork
*
*/

package atm.physical;
import atm.ATM;
import banking.Card;
import simulation.Simulation;

/** Manager for the ATM's card reader. In a real ATM, this would
* manage a physical device; in this simulation, it uses classes
* in package simulation to simulate the device.
*/

public class CardReader
{
/** Constructor
*
* @param atm the ATM that owns this card reader
*/
public CardReader(ATM atm)
{
this.atm = atm;
}

// In a real ATM, code would be needed to sense insertion of a card into the
// slot and notify the ATM - simulated in this case by a button in the GUI

/** Read a card that has been partially inserted into the reader
*
* @return Card object representing information on the card if read
* successfully, null if not read successfully
*/
public Card readCard()
{
return Simulation.getInstance().readCard();
}

/** Eject the card that is currently inside the reader.
*/
public void ejectCard()
{
Simulation.getInstance().ejectCard();
}

/** Retain the card that is currently inside the reader for action by the
* bank.
*/
public void retainCard()
{
Simulation.getInstance().retainCard();
}

/** The ATM to which this card reader belongs
*/
private ATM atm;
}
</pre>

=Teaching Exercises for CRC=
We read many webpages and we selected the ones below as the most suitable examples for different teaching purposes.

==Exercise for Teaching Interactively over the Web==
Of course the ATM machine example mentioned above is a very good case to study and to teach interactively over the web, since the content is detailed and each class in it is a good exercise to practice using CRC card. Besides the ATM website, another website [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ Object Oriented Analysis and Design using CRC Cards] is also very instructive and worth reading.

This website is an online tutorial for how to use CRC card. The tutorial contains two stages: CRC card for analysis and CRC card for design. In the analysis stage there are two activities. The first one is to design an operation system for a technical library for an R&D organization. The author provides a list of possible classes for readers to choose and analyze. The second activity is to stabilize the system by consider more possible flaws of the system. The author summarize the strength of CRC card for analysis are:

*Common Project Vocabulary
*Spread Domain Knowledge
*Making the Paradigm Shift
*Live Prototyping
*Identifying Holes in Requirements

In the design stage the author lists some major elements for CRC design and some additional information to be added to cards in this stage: subresponsibilities, collaborating responsibilities and the data passed. There is the third activity to redo the scenarios in the analysis stage, with consideration of all design heuristics discussed. The author summarize the strength of CRC card for design are:

*Spreading Objet-Oriented Design Expertise
*Design Reviews
*Framework for Implementation
*Informal Notation

All in all, the material in this tutorial is in detail, and is suitable to be used for teaching interactively over web. The teacher could add more features and more detailed thinkings to the activites and the students could practice based on the tutorial.

==Exercise for Teaching in a Class==

There is an example of how to use role playing to teach OO design through CRC cards by [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf Jürgen Börstler] Umeå University, Sweden. It not only works well at teaching CRC cards in class but also a good activity in class. Divide class into groups. Each member in the group presents an object (a CRC card). They can only think of their role. Their responsibilities and how they collaborate with others. Via this way, students can know how to define each CRC card by naming each role; to list what each role can do is to understand how to list responsibilities; to interact with other roles helps to figure out the collaborator of CRC cards.
It takes a small library system as example. There are four roles:
*Book
*Librarian
*Borrower
*Date
[[Image:Library diagram.JPG]]
Each student play a role to discuss with others.
[[Image:roles.jpg]]

==Exercise for Self-study==
Here is a good web page (http://www.agilemodeling.com/artifacts/crcModel.htm) for CRC cards self-study. It simple describes CRC cards at first and using an easy example to teach the rest. The example has only three main roles, student, seminar and professor. Because it’s an example relate to the student experience so it’s easy to understand.

*First, find the classes and how to name the classes.
*Second, find the responsibility.
*Third, define the collaborators to find out how each role interactive with others.
*Forth, move the cards around to more clearly figure out the relation of each class.
Why I think this is a good web site for self study? The example here is easy and close to student’s experience, therefore student can understand easily without others help.

=Reference=
* [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration Card]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Class Responsibility Collaborator (CRC) Models]
* [http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ CRC Cards Tutorial]
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989]
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995]
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card]
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation]
* [http://www.cs.umu.se/~jubo/Papers/CRC_CeTUSS07.pdf CRC-Cards and Roleplay Diagrams Informal Tools to Teach OO Thinking]