Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:40:31Z

Naruto: /* Magic Pushbutton */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
Some of the important software design anti-patterns are,
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts([http://en.wikipedia.org/wiki/Client-server client-server] to [http://en.wikipedia.org/wiki/Web-based web based], file based to [http://en.wikipedia.org/wiki/Database database based] etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the [http://en.wikipedia.org/wiki/Business_Logic business logic] in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 

===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] 
[2] http://www.antipatterns.com/ 
[3] http://c2.com/cgi/wiki?AntiPattern 
[4] http://www.martinfowler.com/bliki/CallSuper.html 
[5] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:40:05Z

Naruto: /* Magic Pushbutton */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
Some of the important software design anti-patterns are,
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts([http://en.wikipedia.org/wiki/Client-server client-server] to [http://en.wikipedia.org/wiki/Web-based web based], file based to [http://en.wikipedia.org/wiki/Database database based] etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the [http://en.wikipedia.org/wiki/Business_Logic business logic] in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 

===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] 
[2] http://www.antipatterns.com/ 
[3] http://c2.com/cgi/wiki?AntiPattern 
[4] http://www.martinfowler.com/bliki/CallSuper.html 
[5] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:39:14Z

Naruto: /* Big ball of mud */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
Some of the important software design anti-patterns are,
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts([http://en.wikipedia.org/wiki/Client-server client-server] to [http://en.wikipedia.org/wiki/Web-based web based], file based to [http://en.wikipedia.org/wiki/Database database based] etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 

===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] 
[2] http://www.antipatterns.com/ 
[3] http://c2.com/cgi/wiki?AntiPattern 
[4] http://www.martinfowler.com/bliki/CallSuper.html 
[5] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:38:30Z

Naruto: /* Big ball of mud */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
Some of the important software design anti-patterns are,
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts([http://en.wikipedia.org/wiki/Client-server client-server] to [http://en.wikipedia.org/wiki/Web-based web based], file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 

===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] 
[2] http://www.antipatterns.com/ 
[3] http://c2.com/cgi/wiki?AntiPattern 
[4] http://www.martinfowler.com/bliki/CallSuper.html 
[5] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:36:09Z

Naruto: /* External Links */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
Some of the important software design anti-patterns are,
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 

===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] 
[2] http://www.antipatterns.com/ 
[3] http://c2.com/cgi/wiki?AntiPattern 
[4] http://www.martinfowler.com/bliki/CallSuper.html 
[5] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:34:26Z

Naruto: /* Magic Pushbutton */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
Some of the important software design anti-patterns are,
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:33:56Z

Naruto: /* Magic Pushbutton */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
* The code for in those defined functions grow large.
* Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
* Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
* Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:33:04Z

Naruto: /* Race Hazard */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**[http://en.wikipedia.org/wiki/Mutex Mutexes] can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

 
==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:30:39Z

Naruto: /* Abstraction Inversion */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**Mutexes can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==
Some of the important Object-oriented design anti-patterns are,

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:28:56Z

Naruto: /* Abstraction Inversion */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**Mutexes can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behavior (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:28:33Z

Naruto: /* Abstraction Inversion */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers w=equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**Mutexes can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behavior (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:28:05Z

Naruto: /* Overview */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system.
*Inexperience on the part of the programmer.
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers w=equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**Mutexes can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behavior (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:27:43Z

Naruto: /* Overview */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,
*Lack of knowledge by the programmer who coded the system
*Inexperience on the part of the programmer
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers w=equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**Mutexes can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behavior (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T21:27:19Z

Naruto:

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti pattern was used,
*Lack of knowledge by the programmer who coded the system
*Inexperience on the part of the programmer
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==
Some of the widely used anti-patterns are classified into the following categories,
* [http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns Organizational anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Project_management_anti-patterns Project management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Analysis_anti-patterns Analysis anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Software design anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Configuration_management_anti-patterns Configuration management anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns Programming anti-patterns]
* [http://en.wikipedia.org/wiki/Anti-pattern#Methodological_anti-patterns Methodological anti-patterns]

==Software design anti-patterns==
===Abstraction Inversion===
Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below

* '''Example'''
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

* '''Solution'''
**Choose the infrastructure carefully.
**If the system offers w=equivalent functions, use them.
**Do not inject any weak constructs into the system.

===Big ball of mud===

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

*'''Example'''
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

*'''Solution'''
**Good understanding of the system prior to any major code changes.
**Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
**Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

*'''Example'''
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

*'''Solution'''
**Mutexes can be used to address this problem in concurrent programming.

===Magic Pushbutton===
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this are,
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
 
*'''Example'''
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

*'''Solution'''
**Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

===Anemic Domain Model===
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
*'''Example'''
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

*'''Solution'''
**Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behavior (debit method) into BankAccnt Class.

 
===BaseBean===
In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

*'''Solution'''
**We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.
 

===CallSuper===
CallSuper is a anti-pattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
*'''Example'''
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==
The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle SDLC life cycle], because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T20:24:09Z

Naruto: /* References */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti pattern was used,
*Lack of knowledge by the programmer who coded the system
*Inexperience on the part of the programmer
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==

==Software design anti-patterns==
===Abstraction Inversion===
====Definition====
Abstarction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below
====Example====
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.
====Solution====
*Choose the infrastructure carefully.
*If the system offers w=equivalent functions, use them.
*Do not inject any weak constructs into the system.

===Big ball of mud===
====Definition====
This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.
====Example====
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

====Solution====
*Good understanding of the system prior to any major code changes.
*Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
*Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
====Definition====
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

====Example====
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

====Solution====
Mutexes can be used to address this problem in concurrent programming.

===Magic Bushbutton===
====Definition====
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
====Example====
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by refactoring the business logic. IN the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

====Solution====
*Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

* Anemic Domain Model
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

Although, the above code looks right by providing segregation of data and service, its in violation of OOP principle of data and behaviour [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are muliple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

* BaseBean
In the practise of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go. We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.

* CallSuper
CallSuper is a antipattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practise because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsiblity on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Abstraction_inversion Abstraction Inversion]
* [http://en.wikipedia.org/wiki/Big_ball_of_mud Big Ball Of Mud]
* [http://en.wikipedia.org/wiki/Race_hazard Race Hazard]
* [http://en.wikipedia.org/wiki/Magic_pushbutton Magic Pushbutton]
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T20:20:03Z

Naruto: /* Example */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti pattern was used,
*Lack of knowledge by the programmer who coded the system
*Inexperience on the part of the programmer
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==

==Software design anti-patterns==
===Abstraction Inversion===
====Definition====
Abstarction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below
====Example====
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.
====Solution====
*Choose the infrastructure carefully.
*If the system offers w=equivalent functions, use them.
*Do not inject any weak constructs into the system.

===Big ball of mud===
====Definition====
This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.
====Example====
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

====Solution====
*Good understanding of the system prior to any major code changes.
*Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
*Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
====Definition====
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

====Example====
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

====Solution====
Mutexes can be used to address this problem in concurrent programming.

===Magic Bushbutton===
====Definition====
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
====Example====
Below is a Bad example of Magic PushButton Anti Pattern.
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

A good example of the same is given below. This is done by refactoring the business logic. IN the below example this is done by storing the file in an registry in a separate class.

type
TReference = class
private
FFilename: string
procedure SetFilename(const Value: string)
public
property Filename:string read FFilename write SetFilename;
procedure Load;
procedure Save;
end

The above code will call Save method from the click handler.
procedure TForm1.ButtonClick (Sender: Object);
begin
Preference.Save;
end;
procedure TForm1.EditChange (Sender: TObject);
begin
Preferences.Filename:= edit1.text;
end;

====Solution====
*Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

==Object-oriented design anti-patterns==

* Anemic Domain Model
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

Although, the above code looks right by providing segregation of data and service, its in violation of OOP principle of data and behaviour [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are muliple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

* BaseBean
In the practise of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go. We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.

* CallSuper
CallSuper is a antipattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practise because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsiblity on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T19:51:52Z

Naruto: /* Definition */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti pattern was used,
*Lack of knowledge by the programmer who coded the system
*Inexperience on the part of the programmer
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==

==Software design anti-patterns==
===Abstraction Inversion===
====Definition====
Abstarction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below
====Example====
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.
====Solution====
*Choose the infrastructure carefully.
*If the system offers w=equivalent functions, use them.
*Do not inject any weak constructs into the system.

===Big ball of mud===
====Definition====
This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.
====Example====
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

====Solution====
*Good understanding of the system prior to any major code changes.
*Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
*Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
====Definition====
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

====Example====
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

====Solution====
Mutexes can be used to address this problem in concurrent programming.

===Magic Bushbutton===
====Definition====
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.
====Example====
procedure TForm1.ButtonClick(Sender: TObject);
var
reg:TRegistry;
begin
reg:TRegistry.Create;
try
reg.RootKey:= HKey_Current_User;
if reg.OpenKey('\Software\mycompany',true) then
begin
reg.WriteString('Filename',edit1.text);
end;
finally
reg.Free;
end
end

==Object-oriented design anti-patterns==

* Anemic Domain Model
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

Although, the above code looks right by providing segregation of data and service, its in violation of OOP principle of data and behaviour [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are muliple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

* BaseBean
In the practise of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go. We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.

* CallSuper
CallSuper is a antipattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practise because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsiblity on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T19:46:46Z

Naruto: /* Object-oriented design anti-patterns */

=Anti-patterns=

==Overview==
Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti pattern was used,
*Lack of knowledge by the programmer who coded the system
*Inexperience on the part of the programmer
*Lack of proper understanding of the functionality the system needed to provide.
Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[http://en.wikipedia.org/wiki/Anti-pattern]

==Known classifications==

==Software design anti-patterns==
===Abstraction Inversion===
====Definition====
Abstarction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A.
A short Example of Abstraction Inversion is given below
====Example====
The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the indexer to find the bit.
char[] bitString ...;
if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.
====Solution====
*Choose the infrastructure carefully.
*If the system offers w=equivalent functions, use them.
*Do not inject any weak constructs into the system.

===Big ball of mud===
====Definition====
This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.
====Example====
float CalculateTotal(int quantity, float price){
return quantity*price;
}

float CalculateAmount(int amt, float price){
return amt*price;
}

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

====Solution====
*Good understanding of the system prior to any major code changes.
*Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
*Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

===Race Hazard===
====Definition====
A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

====Example====
global integer A = 0;
//increments the value of A and prints "RX"
// activated whenever an interrupt is received from the controller
task Received()
{
A = A + 1
print RX
}

//prints out only even numbers
//is activated whenever an interrupt is received from the serial controller
task timeout()
{
if(A is divisible by 2)
{
print A
}
}

Output would look like
0
0
0
RX
RX
2
RX
RX
4

====Solution====
Mutexes can be used to address this problem in concurrent programming.

===Magic Bushbutton===
====Definition====
This is a very common anti pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods.
Some of the issues faced in this
*The code for in those defined functions grow large.
*Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
*Testing becomes an issue.

==Object-oriented design anti-patterns==

* Anemic Domain Model
Separating the [http://en.wikipedia.org/wiki/Business_logic business logic] from the [http://en.wikipedia.org/wiki/Domain_model Domain Model] is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's [http://en.wikipedia.org/wiki/Entity_Bean Entity beans] and .Net's three layered service application. A short example for Anaemic Model is given below,
class BankAccnt {
private double balance;
public void setBalance(double balance) {
this.balance = balance;
}
class AccntService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
}

Although, the above code looks right by providing segregation of data and service, its in violation of OOP principle of data and behaviour [http://en.wikipedia.org/wiki/Encapsulation encapsulation].It could run into problems when there are muliple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

* BaseBean
In the practise of BaseBean, subclasses are derived from an utility class, even though delegation is possible. [http://en.wikipedia.org/wiki/Inheritance Inheritance] can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go. We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.

* CallSuper
CallSuper is a antipattern in which subclass [http://en.wikipedia.org/wiki/Method_overriding overrides] a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practise because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsiblity on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.
// '''Wrong Way''' // '''Correct Way'''
public class EventHandle{ public class EventHandle{
public void handle (BankingEvent e) { public void handle (BankingEvent e) {
cleanUp(e); cleanUp(e);
} doHandle(e); //hook method
} }
public class TransferEventHandler extends EventHandle{ protected void doHandle(BankingEvent e) {
public void handle(BankingEvent e) { }
super.handle(e); public class TransferEventHandler extends EventHandle{
initiateTransfer(e); protected void doHandle(BankingEvent e) {
} initiateTransfer(e);
}
} }

==Conclusion==

==See also==

* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]
* [http://en.wikipedia.org/wiki/Code_smell Code Smell]

==References==

* [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]
* [http://en.wikipedia.org/wiki/BaseBean BaseBean]

==External Links==

[1] http://www.antipatterns.com/ 
[2] http://c2.com/cgi/wiki?AntiPattern 
[3] http://www.martinfowler.com/bliki/CallSuper.html 
[4] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T19:30:05Z

Naruto: /* Example */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-17T19:29:37Z

Naruto: /* Example */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T04:00:49Z

Naruto: /* Object-oriented design anti-patterns */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:36:18Z

Naruto: /* Example */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:35:27Z

Naruto: /* Object-oriented design anti-patterns */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:22:34Z

Naruto: /* Object-oriented design anti-patterns */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:21:33Z

Naruto: /* Software design anti-patterns */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:20:39Z

Naruto: /* Solution */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:20:21Z

Naruto: /* Abstraction Inversion */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T03:12:28Z

Naruto: /* Object-oriented design anti-patterns */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T02:57:16Z

Naruto: /* Overview */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T02:57:05Z

Naruto: /* Overview */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T02:56:34Z

Naruto: /* Overview */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T02:56:19Z

Naruto: /* Overview */

CSC/ECE 517 Fall 2009/wiki3 1 kp

2009-11-13T02:55:32Z

Naruto: /* Overview */

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-11T01:10:29Z

Naruto:

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
change
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern?==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Implementation in Ruby==
The given code explains how to create a factory in Ruby. In this it initially creates a factory class called GearFactory and overrides the new function. When an object is instantiated the code does not need to know which kind of object it is. It is a collection (hence the word factory) of objects that are clubbed together.
class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Implementation in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}
==Comparison of Implementations==
Both the languages implement the factory design pattern. Java implements the factory design pattern using the interfaces while Ruby uses classes to create a factory. An abstract base class can be defined in Java to hold all the interfaces needed or there could be a parameterised method which takes the kind of object as a parameter to instantiate the necessary object.
In Ruby 'new' is just a method on a class object, it's always free to return anything it likes. The nice thing about this is that, in ruby, every call to new is, by definition, the factory pattern - it just so happens that there is a default implementation inherited by class 'Class'.
The factory implementation of Ruby is a lot simpler than the factory implementation of Java.

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:41:05Z

Naruto:

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern?==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Implementation in Ruby==
The given code explains how to create a factory in Ruby. In this it initially creates a factory class called GearFactory and overrides the new function. When an object is instantiated the code does not need to know which kind of object it is. It is a collection (hence the word factory) of objects that are clubbed together.
class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Implementation in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}
==Comparison of Implementations==
Both the languages implement the factory design pattern. Java implements the factory design pattern using the interfaces while Ruby uses classes to create a factory. An abstract base class can be defined in Java to hold all the interfaces needed or there could be a parameterised method which takes the kind of object as a parameter to instantiate the necessary object.
In Ruby 'new' is just a method on a class object, it's always free to return anything it likes. The nice thing about this is that, in ruby, every call to new is, by definition, the factory pattern - it just so happens that there is a default implementation inherited by class 'Class'.
The factory implementation of Ruby is a lot simpler than the factory implementation of Java.

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:29:57Z

Naruto: /* Implementation in Ruby */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern?==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Implementation in Ruby==
The given code explains how to create a factory in Ruby. In this it initially creates a factory class called GearFactory and overrides the new function. When an object is instantiated the code does not need to know which kind of object it is. It is a collection (hence the word factory) of objects that are clubbed together.
class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Implementation in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:25:47Z

Naruto: /* What is Factory Design Pattern */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern?==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Implementation in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Implementation in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:25:31Z

Naruto: /* Factory Example in Ruby */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Implementation in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Implementation in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:25:13Z

Naruto: /* Factory Example in Java */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Implementation in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:24:46Z

Naruto: /* Factory */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory Design Pattern=
==What is Factory Design Pattern==
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:22:52Z

Naruto: /* Factory Example in Ruby */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the following code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:22:21Z

Naruto: /* Factory */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate the code that creates the class form the concrete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:21:39Z

Naruto: /* Factory */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:19:48Z

Naruto: /* References */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactory explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:19:16Z

Naruto: /* References */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory SourceMaking explains Abstract Factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactiry explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:18:16Z

Naruto:

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

=References=
#[http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf Design Patterns]
#[http://www.patterndepot.com/put/8/JavaPatterns.htm Design Patterns Java Companion James W Cooper]
#[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Wiki Design Patterns]
#[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Method]
#[http://sourcemaking.com/design_patterns/abstract_factory]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf Abstract Factory Example in Java]
#[http://www.dofactory.com/Patterns/PatternAbstract.aspx Abstract Factory explained]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator Pattern]
#[http://sourcemaking.com/design_patterns/iterator Sourcemaking explains Iterator method]
#[http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf Iterator method explained]
#[http://www.dofactory.com/Patterns/PatternIterator.aspx DoFactiry explains Iterator pattern]
#[http://us3.php.net/manual/en/language.oop5.iterations.php Iterator pattern for PHP]
#[http://www.patterndepot.com/put/8/Decorator.pdf Decorator Pattern]
#[http://en.wikipedia.org/wiki/Decorator_pattern Wiki Decorator Pattern]
#[http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby Design Patterns in Ruby]
#[http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript Design Patterns Javascript]

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-09T00:03:56Z

Naruto: /* Introduction */

''What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.''

=Introduction=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
"The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past" [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem. Design patterns can be classified into 3 parts [http://en.wikipedia.org/wiki/Creational_pattern Creational], [http://en.wikipedia.org/wiki/Structural_pattern Structural], [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] [http://www.patterndepot.com/put/8/JavaPatterns.htm].

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=Abstract Factory Pattern=
==What is Abstract Factory Pattern?==
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. The Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

==Implementation in Ruby==
Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

==Implementation in Java==
In Java, implementing Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. In Java, Abstract Factory defines a different method for the creation of each product it can produce. The following example shows an implementation of Abstract Factory design pattern in Java.

public class FactoryFmProto {
static class Expression {
protected String str;
public Expression( String s ) { str = s; }
public Expression cloan() { return null; }
public String toString() { return str; }
}
static abstract class Factory {
protected Expression prototype = null;
public Expression makePhrase() { return prototype.cloan(); }
public abstract Expression makeCompromise();
public abstract Expression makeGrade();
}
static class PCFactory extends Factory {
public PCFactory() { prototype = new PCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"do it your way, any way, or no way\"" ); }
public Expression makeGrade() {
return new Expression( "\"you pass, self-esteem intact\"" ); }
}
static class NotPCFactory extends Factory {
public NotPCFactory() { prototype = new NotPCPhrase(); }
public Expression makeCompromise() {
return new Expression( "\"my way, or the highway\"" ); }
public Expression makeGrade() {
return new Expression( "\"take test, deal with the results\"" ); }
}
public static void main( String[] args ) {
Factory factory;
if (args.length > 0) factory = new PCFactory();
else factory = new NotPCFactory();
for (int i=0; i < 3; i++) System.out.print( factory.makePhrase() + " " );
System.out.println();
System.out.println( factory.makeCompromise() );
System.out.println( factory.makeGrade() );
}
}

==Comparison of Implementations==
Basically, Java and Ruby, both can implement Abstract Factory design pattern. But the more important point is the simplicity by which they can apply it. Ruby automatically implements the Abstract Factory pattern as Class Objects. But Java needs helps of interfaces and classes to do so. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

Similarly, C# demonstrates the Abstract Factory pattern by creating parallel hierarchies of objects. Object creation has been abstracted and there is no need for hard-coded class names in the client code. This property helps C# to have better implementation than Java. In .NET, there are built in features such as, generics, reflection, object initializers, automatic properties, etc for implementation [http://www.dofactory.com/Patterns/PatternAbstract.aspx].

=Iterator Design Pattern=
==What is Iterator Design Pattern?==
The Iterator design pattern allows an object to encapsulate the internal structure and allows the user to move through the collection of data using standard interface. It is one of the simplest and most frequently used design pattern. It is a type of Behavioral design pattern [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

==Implementation in Ruby==
Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

==Implementation in Java==

In Java, we can implement Iterator design pattern by using java.util.Enumeration interface which returns a reference to an object. Furthermore, Hashes and Vector have limited capabilities which help simple traversing. Java JDK 1.2 introduced a new Collections package with more aggregate classes, including sets, lists, maps and an Iterator interface. If we wanted to start implementing Iterator design pattern from start, then it would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf]. For example, consider the following scenario where iterator.First() and iterator.Next(), has been implemented in the class ListIterator.

...
List list = new List();
...
ListIterator iterator = new ListIterator(list);
iterator.First();
while (!iterator.IsDone()) {
Object item = iterator.CurrentItem();
// Code here to process item.
iterator.Next();
}
...

==Comparison of Implementations==

Overall implementation of Iterator design pattern in each object oriented language is simple as it is a basis feature of objects. But in general, the Ruby implementation is more concise. Ruby has built-in iterators which make it easier to implement Iterator pattern for any kind of object. It hides the structure and there is no need for having implementation for those methods in the class. But in Java, the built-in library function help to create easier and clear implementations. C# also has similar implementation as Java for this design pattern [http://www.dofactory.com/Patterns/PatternIterator.aspx].

In PHP, using an object in a foreach structure will traverse the public values. There are also many multiple Iterator classes available to allow us to iterate through common lists, such as directories, XML structures and recursive arrays. We can also implement our own interfaces depending on requirement [http://us3.php.net/manual/en/language.oop5.iterations.php].

=Decorator Pattern=

This pattern is used to increase the functionality of the existing object dynamically. Suppose we have a program that uses eight objects, but three of them need an additional feature. We could create derived class for these objects having the additional features but then we can create a Decorator class which will add any specific kind of feature required [http://www.patterndepot.com/put/8/Decorator.pdf]. It is a type of behavioral pattern.

==Implementation in Ruby==

Generic decorators can be implmented by using the method_missing method. This method is called when an object receives a message that it does not have a method fo. The method_missing method can forward the message on to other object and wrap additional behavior around the call. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9. The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it. The need for this kind of pattern is so as to increase the functionality of a particular class [http://en.wikipedia.org/wiki/Decorator_pattern].

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

There are various other options to implement this design pattern. Other way to implememt the pattern is by using singleton methods and method aliases. Delegation can also be used, and it overcomes one of the most important disadvantage. We can remove add features if we are using delegation but this is not possible if we are using singleton methods and method aliases. Example for this can be found here [http://www.scribd.com/doc/2217773/Design-Patterns-in-Ruby].

==Implementation in Java==

In Java, this pattern is easy to implement by dividing the various responsibilities into classes and interfaces. The below example consider all these responsibilities and have four components which are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

==Comparison of implementations==

Ruby provides different options to implement Decorator pattern like method_missing, delegation and alias methods. This provides flexibility to the user to implement any possible way depending on the requirements and features needed. But in Java, there is more clearer approach using the components provided in the example. It is a straight forward approach. But different options provided by Ruby make it much better than Java.

In dynamic languages like Javascript, decorator pattern can be implemented with no interfaces or traditional OOP inheritance. With simple overriding but this approach is difficult to implement [http://en.wikipedia.org/wiki/Decorator_pattern#JavaScript].

=Conclusion=

We have seen four design patterns Factory design pattern, Abstract Factory design pattern, Iterator design pattern and Decorator Design Pattern. We have chosen these patterns as they are widely used and Ruby has in-built implementations of these. We have mainly tried to compare Ruby and Java but also specified tips about other languages like PHP, C# and Javascript. In Ruby implementing these design patterns is simple and easy because of its main feature of private class objects, unbounded polymorphism and duck typing [http://people.engr.ncsu.edu/efg/517/f07/lectures/notes/lec6.pdf]. In Java all the features are mainly implemented through interfaces and classes. This has several disadvantages like increase in code complexity, size and is generally confusing and tedious to trace or understand the code.

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-07T23:58:28Z

Naruto: /* Decorator Pattern */

=Overview=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past.
A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem.
Design patterns c an be classified into 3 parts
Creational, Structural, Behavioral (See if we can give links for these.)

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=AbstractFactory Model=
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

But in Java for implementation of Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class.
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

=Iterator Design Pattern=
An Iterator object encapsulates the internal structure of how the iteration occurs. It is a type of Behavioral design pattern. [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

In Java implementing Iterator design pattern would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class. [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf] Thus Ruby helps in implementing this design pattern easily by providing functions like “each” which does the handling of the concrete class implementation.

=Decorator Pattern=
It is used to increase the functionality of the existing object dynamically. It adds the behavior at runtime.
The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it.
The need for this kind of pattern is so as to increase the functionality of a particular class.

==Decorator Example in Ruby==
In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9.
module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

==Decorator Example in Java==
The components for this example are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-07T23:56:34Z

Naruto: /* Decorator Example in Java */

=Overview=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past.
A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem.
Design patterns c an be classified into 3 parts
Creational, Structural, Behavioral (See if we can give links for these.)

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=AbstractFactory Model=
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

But in Java for implementation of Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class.
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

=Iterator Design Pattern=
An Iterator object encapsulates the internal structure of how the iteration occurs. It is a type of Behavioral design pattern. [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

In Java implementing Iterator design pattern would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class. [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf] Thus Ruby helps in implementing this design pattern easily by providing functions like “each” which does the handling of the concrete class implementation.

=Decorator Pattern=
It is used to increase the functionality of the existing object dynamically. It adds the behavior at runtime.
The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it.
The need for this kind of pattern is so as to increase the functionality of a particlar class. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9.

==Decorator Example in Ruby==
module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

==Decorator Example in Java==
The components for this example are described below
* Component: Defines the interface for objects that can have responsibilities added to them dynamically.
* ConcreteComponent: Defines an object to which additional responsibilities can be attached.
* Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
* ConcreteDecorator: adds responsibilities to the component.

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}

CSC/ECE 517 Fall 2009/wiki2 11 zv

2009-10-07T23:37:36Z

Naruto: /* Decorator Example in Java */

=Overview=
Before starting off with design patterns for Ruby we need to define what a design pattern is, Design patterns can be described as "a general reusable solution to a commonly occurring problem in software design." [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]
The idea of design patterns is to not to reinvent the wheel but to solve the current problems by using solutions that have worked in the past.
A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It helps to identify the classes and instances and the way they collaborate with each other to form a solution to a problem.
Design patterns c an be classified into 3 parts
Creational, Structural, Behavioral (See if we can give links for these.)

=Factory=
Factories
The factory design pattern is an object oriented design pattern. It is a creational design pattern and deals with the issues faced in creating objects.
The main goal of this implementation is to isolate teh code that creates the class form the concete implementation of that class. Ruby example for the same is given below.

==Factory Example in Ruby==

class GearFactory
def new()
if ( ... some condition )
return Sprocket.new()
else
return Cog().new()
end
end
end

Our client class now becomes:
class GearUser
def doSomething(factory )
...
my_gear = factory.new()
...
end
end

The above code does not have to distinguish between a factory and an ordinary class. We can call the class using the followijng code.
client.doSomething(GearFactory.new) #Use the factory
client.doSomething(Cog) #Use the Cog class
client.doSomething(Sprocket) #Use the Sprocket class

==Factory Example in Java==
In java the Factory implementation is done using interfaces. Declaring them as interfaces helps to maintain a general overview and not depending on the type of factory object that needs to be used. All of these can be placed in a huge factory in a client application.
A well known example for Java Factory is the UI toolkits that are designed to run on different windowing systems.
interface ScrollBar { ... }
interface MenuBar { ... }
...
And associated classes implementing them on different windowing systems:

class MotifScrollBar implements ScrollBar { ... }
class Win95ScrollBar implements ScrollBar { ... }
...

And a factory interface that also doesn't commit to representation:

interface Factory {
public abstract ScrollBar newScrollBar();
public abstract MenuBar newMenuBar();
...
}

But implementation classes that do:

class MotifFactory implements Factory {
public ScrollBar newScrollBar() { return new MotifScrollBar(...); }
...
}

=AbstractFactory Model=
Abstract Factory Design Pattern encapsulates a group of objects that have common theme. It implements a generic interface to create these objects that are part of the theme. It does not care about the details of the implementation of these objects. It is a type of Creational pattern [http://en.wikipedia.org/wiki/Abstract_factory_pattern] “Provide an interface for creating families of related or dependent objects without specifying their concrete classes” [http://sourcemaking.com/design_patterns/abstract_factory]

Ruby automatically implements the Abstract Factory pattern as Class Objects. All Class objects have the same interface: the new method of each class object creates new instances of the class. Thus the code can pass references to class objects around and they can be used to call new method without knowing the exact type of object that the class creates.

Class Foo; end
Class Bar, end

Here is the use of Abstract Factory Pattern

def create_something(factory)
new_object = factory.new
puts "created a new #{new_object.class} with a factory"
end

Here we select a factory to use
Create_something(Foo)
Create_something(Bar)

Output of the code: 
Created a Foo with a factory 
Created a Bar with a factory

The create_something method is creating objects through an abstract interface. It does not have details about implementation used to create these objects. Thus the use of create_something() is used to shield the rest of the code from that knowledge.

But in Java for implementation of Abstract Factory design pattern we need to create a class which has method who defers creation of product objects to its concrete class. This class then needs to be ”extended” by the client class which uses only these interfaces to create objects of concrete class.
[http://userpages.umbc.edu/~tarr/dp/lectures/Factory-2pp.pdf]. Thus Java implementation needs a well defined interface to do so but in Ruby it is directly implemented because of private class object property.

=Iterator Design Pattern=
An Iterator object encapsulates the internal structure of how the iteration occurs. It is a type of Behavioral design pattern. [http://en.wikipedia.org/wiki/Iterator_pattern]. “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” [http://sourcemaking.com/design_patterns/iterator]

Ruby implements iterators with blocks and the ‘each’ method, and with ‘for..in’ statements. For example consider the following example;

def print_element(container)
Container.each {|o| puts o.inspect }
end

list = [1,2,2,3]
hash = {“a”=>1, “b”=>2,”c”=>3, “d”=>4 }
print_elements list
print_elements hash

The output of the code is,
1
2
3
4
[“a”,1]
[“b”,2]
[“c”,3]
[“d”,4]

In Java implementing Iterator design pattern would again involve having an interface for accessing and traversing the elements which is further implemented by the concrete class. Thus a class who needs to access the list will need to call the interface class. [http://userpages.umbc.edu/~tarr/dp/lectures/Iterator-2pp.pdf] Thus Ruby helps in implementing this design pattern easily by providing functions like “each” which does the handling of the concrete class implementation.

=Decorator Pattern=
It is used to increase the functionality of the existing object dynamically. It adds the behavior at runtime.
The below code is an example of decorators where we just create a place holder and we can use this function to perform different functions depending on the parameters supplied to it.
The need for this kind of pattern is so as to increase the functionality of a particlar class. In this example we talk about how a coffee class can have many addtions to it like coffee with cream, sprinkles, milk etc and creating a class for each of them will not be the correct solution.In this example the cost can be calculated according to what is sent to it.Cost of the coffee is 2 and the cost of White coffee (coffee + milk) = 2.4. So what happens when we execute the Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost we get the result as 2.9 as the cost of the coffee is 2, the decorator object (now only coffee) is sent to the Milk and it becomes 2.4, which now is then sent to the Whip which is going to be 2.4 + 02 = 2.6 and finally to Sprinkles which becomes 2.6 + 0.3 = 2.9.

==Decorator Example in Ruby==
module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

class Whip
include Decorator
def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

==Decorator Example in Java==

package decorator;
public interface IComponent {
public void doStuff();
}

The Concrete component
package decorator;
public class Component implements IComponent{
public void doStuff() {
System.out.println("Do Suff");
}
}

The Decorator
package decorator;
public interface Decorator extends IComponent {
public void addedBehavior();
}

The Concrete Decorator ('''Extends IComponent''')
package decorator;
public class ConcreteDecorator implements Decorator {
IComponent component;
public ConcreteDecorator(IComponent component) {
super();
this.component = component;
}
public void addedBehavior() {
System.out.println("Decorator does some stuff too");
}
public void doStuff() {
component.doStuff();
addedBehavior();
}
}

The Client

import decorator.*;
public class Client {
public static void main(String[] args) {
IComponent comp = new Component();
Decorator decorator = new ConcreteDecorator(comp);
decorator.doStuff();
}
}