Professional Documents
Culture Documents
Creational Design Patterns
Creational Design Patterns
In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to
create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or
added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.
Creational design patterns are composed of two dominant ideas. One is encapsulating knowledge about which concrete
classes the system uses. Another is hiding how instances of these concrete classes are created and combined.
Creational design patterns are further categorized into Object-creational patterns and Class-creational patterns, where
Object-creational patterns deal with Object creation and Class-creational patterns deal with Class-instantiation. In greater
details, Object-creational patterns defer part of its object creation to another object, while Class-creational patterns defer
its object creation to subclasses.
Product: defines a product object to be created by the corresponding concrete factory implements the AbstractProduct
interface
Page 1 of 12
C# Example 1:
interface IDumb
{
string Name();
}
interface ISmart
{
string Name();
}
Page 2 of 12
So we have all the concrete classes ready for all the Dumb Phones and smart phones irrespective of their
manufacturers.
Now the way we associate these Concrete products with their manufacturers is using the Concrete factories. But before
having the concrete factories, we need to have an Abstract Factory.
Page 3 of 12
Creating the Client
Now we have all the Abstract product classes ready, all the Concrete Product classes ready. Our Abstract Factory is
ready and all the Concrete Factories are ready. Now we can write client that will use this hierarchy of related products
to create the products.
enum MANUFACTURERS
{
SAMSUNG,
HTC,
NOKIA
}
class PhoneTypeChecker
{
ISmart sam;
IDumb htc;
IPhoneFactory factory;
MANUFACTURERS manu;
public PhoneTypeChecker(MANUFACTURERS m)
{
manu = m;
}
checker.CheckProducts();
Console.ReadLine();
checker.CheckProducts();
Console.ReadLine();
checker.CheckProducts();
Console.Read();
}
Now we can say we have a basic skeleton for the Abstract factory pattern ready. The concrete products here are not
telling anything but names of products but they can contain more information too. Before we end the show, we can
have a class diagram for the classes we created so that we can use this to map it with the GOFs diagram.
Page 4 of 12
Example 2:
Page 5 of 12
Factory Code will be as follows
public interface IMachineFactory
{
IProcessor GetRam();
IHardDisk GetHardDisk();
IMonitor GetMonitor();
}
processor.PerformOperation();
hdd.StoreData();
monitor.DisplayPicture();
}
}
//Client Code
IMachineFactory factory = new HighBudgetMachine();// Or new LowBudgetMachine();
ComputerShop shop = new ComputerShop(factory);
shop.AssembleMachine();
Page 6 of 12
Factory Method Pattern:
Class structure
Problem Statement
Page 7 of 12
Simple Factory
This is one of the pattern not born from GOF and most of the peopleconsiders this as the default Factory method
pattern. Here, we will just take out object creation process out of the client code and put into some other class. Look at
the code demonstration.
class CustomerFactory
{
public static ICustomer GetCustomer(int i)
{
switch (i)
{
case 1:
GoldCustomer goldCustomer = new GoldCustomer();
goldCustomer.GoldOperation();
goldCustomer.AddPoints();
goldCustomer.AddDiscount();
return goldCustomer;
case 2:
SilverCustomer silverCustomer = new SilverCustomer();
silverCustomer.SilverOperation();
silverCustomer.AddPoints();
silverCustomer.AddDiscount();
return silverCustomer;
default: return null;
}
}
}
//Client Code
ICustomer c = CustomerFactory.GetCustomer(someIntegerValue);
In this pattern we define an interface which will expose a method which will create objects for us. Return type of that
method is never be a concrete type rather it will be some interface (or may be an abstract class)
using System;
class SingletonPattern {
if (s1 == s2) {
Console.WriteLine("Objects are the same instance");
}
}
}
Lazy Initialization:
public class SingletonDemo {
private static SingletonDemo instance = null;
private SingletonDemo() { }
public static synchronized SingletonDemo getInstance() {
if (instance == null) {
instance = new SingletonDemo();
}
return instance;
}}
Eager initialization
public class Singleton {
private static final Singleton INSTANCE = new Singleton();
private Singleton() {}
Page 9 of 12
Behavioural Design Patterns:
Command Pattern:
definition
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests,
and support undoable operations.
participants
• Command (Command)
o declares an interface for executing an operation
• ConcreteCommand (CalculatorCommand)
o defines a binding between a Receiver object and an action
o implements Execute by invoking the corresponding operation(s) on Receiver
• Client (CommandApp)
o creates a ConcreteCommand object and sets its receiver
• Invoker (User)
o asks the command to carry out the request
• Receiver (Calculator)
o knows how to perform the operations associated with carrying out the request.
Page 10 of 12
Example Code:
using System;
using System.Collections.Generic;
namespace CommandPattern
{
public interface ICommand
{
void Execute();
}
Page 11 of 12
/* The Command for turning off the light - ConcreteCommand #2 */
public class FlipDownCommand : ICommand
{
private Light _light;
Page 12 of 12