Expertiza_Wiki - User contributions [en]

File:UML.png

2012-10-23T19:01:01Z

Avsarang:

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T19:00:39Z

Avsarang: /* Headline text */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== UML Diagram ==
[[File:UML.png]]

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T19:00:15Z

Avsarang: /* Abstract Factory */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Headline text ==
UML Diagram
[[File:UML.png]]

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:59:33Z

Avsarang: /* Abstract Factory */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Headline text ==
UML Diagram
[[File:Example.jpg]]

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:58:52Z

Avsarang: /* UML Diagram */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:58:18Z

Avsarang: /* Abstract Factory */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

== UML Diagram ==
[[File:UML.png]]

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:19:30Z

Avsarang: /* Abstract Factory */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

== UML Diagram ==

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:15:31Z

Avsarang: /* Example */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Examples ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:15:13Z

Avsarang: /* Java */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:14:12Z

Avsarang: /* Ruby */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

== Java ==
Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display different messages depending on the type of operating system it is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

interface Buttonlike {
public void paint();
}

interface GUIFactorylike {
public Buttonlike createButton();
}

class WinFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new WinButton();
}
}

class OSXFactory implements GUIFactorylike {
public Buttonlike createButton() {
return new OSXButton();
}
}

class WinButton implements Buttonlike {
public void paint() {
System.out.println("I'm a WinButton");
}
}

class OSXButton implements Buttonlike {
public void paint() {
System.out.println("I'm an OSXButton");
}
}

class Application {
public Application(GUIFactorylike factory) {
Buttonlike button = factory.createButton();
button.paint();
}
}

public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}

public static GUIFactorylike createOsSpecificFactory() {
int sys = readFromConfigFile("OS_TYPE");
if (sys == 0) return new WinFactory();
else return new OSXFactory();
}
}

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:05:03Z

Avsarang: /* Ruby */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==

== Ruby ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-23T18:04:47Z

Avsarang: /* Example */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==

== Ruby ==
class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects. The Director need not know how the object is created. By just asking for the ''Computer'' configuration we need, the ''ComputerBuilder'' class generates the required object.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer. This is done in the ''Director'' class which specifies the configuration of ''Computer'' required.

class Director
builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer
end

===Java===
Not lets have a look at the same example in Java:

==Class Diagram==
Lets look at the class diagram for the Builder Pattern:

[[File:BuilderPattern.png]]

The client of the ''ComputerBuilder'' i.e the code which instantiates the ''ComputerBuilder'' object is called the [http://sourcemaking.com/design_patterns/builder#permalink-5 Director]. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T23:19:31Z

Avsarang: /* Ruby */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

== Ruby ==
class Tiger
# Tiger specific class implementation
end

class Tree
# Tree specific class implementation
end

class Frog
# Frog specific class implementation
end

class Algae
# Algae specific class implementation
end

class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer:

builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer

===Java===
Not lets have a look at the same example in Java:

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T23:17:05Z

Avsarang: /* Ruby */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

== Ruby ==
class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
pond = Habitat.new( 2, 4, PondOrganismFactory.new)

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer:

builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer

===Java===
Not lets have a look at the same example in Java:

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T23:13:34Z

Avsarang: /* Example */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==
Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

== Ruby ==
class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
jungle.simulate_one_day
pond = Habitat.new( 2, 4, PondOrganismFactory.new)
pond.simulate_one_day

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer:

builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer

===Java===
Not lets have a look at the same example in Java:

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T23:06:26Z

Avsarang: /* Ruby */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==
The output will be either "" or "" depending on what kind of Factory is used. As you can see, the client does not know what kind of Factory it is given.

== Ruby ==
class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
jungle.simulate_one_day
pond = Habitat.new( 2, 4, PondOrganismFactory.new)
pond.simulate_one_day

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer:

builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer

===Java===
Not lets have a look at the same example in Java:

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T23:05:25Z

Avsarang: /* Ruby */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==
The output will be either "" or "" depending on what kind of Factory is used. As you can see, the client does not know what kind of Factory it is given.

== Ruby ==
class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

class JungleOrganismFactory
def new_animal(name)
Tiger.new(name)
end
def new_plant(name)
Tree.new(name)
end
end

class Habitat
def initialize(number_animals, number_plants, organism_factory)
@organism_factory = organism_factory

@animals = []
number_animals.times do |i|
animal = @organism_factory.new_animal("Animal#{i}")
@animals << animal
end

@plants = []
number_plants.times do |i|
plant = @organism_factory.new_plant("Plant#{i}")
@plants << plant
end
end
end

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

jungle = Habitat.new(1, 4, JungleOrganismFactory.new)
jungle.simulate_one_day
pond = Habitat.new( 2, 4, PondOrganismFactory.new)
pond.simulate_one_day

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.

==Example==
Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size.

===Ruby===
Lets define a ''Computer'' and other related objects in Ruby<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer:

builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer

===Java===
Not lets have a look at the same example in Java:

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:58:04Z

Avsarang: /* Abstract Factory */

=Abstract Factory and Builder Patterns=

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - [http://www.patternlanguage.com/leveltwo/ca.htm Christopher Alexander]

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in [http://en.wikipedia.org/wiki/Object-oriented_programming Object - Oriented Languages] help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

__TOC__

=Creational Patterns=
Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities <ref>Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from www.pearsonhighered.com/samplechapter/0130935387.pdf</ref>:
* Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
* Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
* Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system. The Singleton Pattern is an example of this type.

=Abstract Factory=
The basic purpose of the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".<ref>^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."</ref>

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:<ref>http://en.wikipedia.org/wiki/Abstract_factory_pattern</ref>
*The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
*Adding new concrete types is done by modifying the client code to use a different factory, a modification that is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before – thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object

== Example ==
The output will be either "" or "" depending on what kind of Factory is used. As you can see, the client does not know what kind of Factory it is given.

== Ruby ==
class PondOrganismFactory
def new_animal(name)
Frog.new(name)
end
def new_plant(name)
Algae.new(name)
end
end

=Builder=
The [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern] is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects<ref>(2012, October 17). Builder pattern. Retrieved from Wikipedia website: http://en.wikipedia.org/wiki/Builder_pattern</ref>.

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations<ref>(n.d.). Builder pattern. Retrieved from OODesign website: http://www.oodesign.com/builder-pattern.html</ref>. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.

Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display.
Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size. Lets define a ''Computer'' and other related objects<ref>Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley. </ref>:

class Computer
attr_accessor :display
attr_accessor :motherboard
attr_reader :drives
def initialize(display=:low-def, motherboard=Motherboard.new, drives=[])
@motherboard = motherboard
@drives = drives
@display = display
end
end

class CPU
# CPU details...
end

class DualCoreCPU < CPU
# DualCore CPU details...
end

class QuadCoreCPU < CPU
# QuadCore CPU details...
end

class Motherboard
attr_accessor :cpu
attr_accessor :memory_size
def initialize(cpu=DualCoreCPU.new, memory_size=1000)
@cpu = cpu
@memory_size = memory_size
end
end

class Drive
attr_reader :type # either :hard_disk, :blu_ray or :dvd
attr_reader :size # in MB
attr_reader :writable # true if this drive is writable
def initialize(type, size, writable)
@type = type
@size = size
@writable = writable
end
end

We can then define a ''ComputerBuilder'' class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
attr_reader :computer
def initialize
@computer = Computer.new
end
def turbo(has_turbo_cpu=true)
@computer.motherboard.cpu = TurboCPU.new
end
def display=(display)
@computer.display=display
end
def memory_size=(size_in_mb)
@computer.motherboard.memory_size = size_in_mb
end
def add_blu_ray(writer=false)
@computer.drives << Drive.new(:blu_ray, 760, writer)
end
def add_dvd(writer=false)
@computer.drives << Drive.new(:dvd, 4000, writer)
end
def add_hard_disk(size_in_mb)
@computer.drives << Drive.new(:hard_disk, size_in_mb, true)
end
end

Now the ''ComputerBuilder'' object can be used to specify the configuration needed on the Computer:

builder = ComputerBuilder.new
builder.turbo
builder.add_blu_ray(true)
builder.add_hard_disk(100000)
computer = builder.computer

=Comparison=

=References=
<references />

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:54:42Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:39:00Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:32:01Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:30:26Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:26:46Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:20:39Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:18:18Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:17:56Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:16:43Z

Avsarang: /* Abstract Factory */

CSC/ECE 517 Fall 2012/ch2a 2w18 as

2012-10-20T22:08:48Z

Avsarang: /* Abstract Factory */