Creational
Patterns
Dr. Himanshu Hora
SRMS college of Engineering & Technology
Bareilly (UP) INDIA
Contents
 Introduction
 Types of Creational Pattern
 Why use Creational Pattern
 The Factory Pattern
 The factory Design Pattern
 Abstract factory
 The Singleton
 Summary
 References
Introduction
 Creational design patterns are design
patterns that deal with object creation
mechanisms, trying to create objects in a
manner suitable to the situation.
Creational Patterns
 There are three creational patterns
 The Factory
 The Abstract Factory
 The Singleton
Why Use A Creational Pattern?
 Some situations are more complex than simple
instantiation can handle.
 Imagine for example you want to create an entirely ‘
skinnable’ look and feel for an application.
 Some situations have complex consequences if
objects aren’t instantiated in the right way or the
right order.
 Some situations require that only one object is
ever created.
The Factory Pattern
 The Factory is used to provide a consistent
interface to setup properly configured objects.
 It can be represented by a single class
containing a single static method.
 More complex factories exist, dealing with more
complex situations.
The Factory Design Pattern
 Imagine a simple class hierarchy:
The Factory Design Pattern
 Now imagine you are creating a simple
drawing package.
 User selects a shape
 User clicks on the screen
 Application draws the shape.
 This can all be hard-coded directly into an
application.
The Factory Design Pattern
 Instead, we use a factory to generate specific
objects, through the power of polymorphism.
 Polymorphism is key to the way a Factory works.
 The system that drives a factory is that all these
shapes have a common parent class.
 All we need is the Shape object that is
represented by specific objects.
Another Example
 Let’s say we have a file that we have created
in our application.
 We now want to export it to a different file
format.
 Each file format has its own peculiarities.
 We could hard-code this into our application.
The Factory Design Pattern
 The Factory Pattern reduces hard-coded
complexity.
 The Factory Pattern properly devolves
responsibility to individual objects.
 However, the Factory pattern by itself is
limited to certain simple contexts.
The Abstract Factory
 The next level of abstraction is the Abstract
Factory.
 This is a Factory for factories.
 Imagine here we have slightly more
complicated situations.
 Designing an interface that allows for
different themes.
 A file conversion application that must allow
for different versions of different formats.
The Abstract Factory
 We could handle these with a factory by itself.
 This introduces the same combinatorial
problems that the factory is designed to
resolve.
 A simple rule to remember is – coding
combinations is usually bad design.
 Bad design causes trouble later on.
 When doing anything more substantial than
simple ‘proof of concept’ applications.
The Consequence
 Entirely new suites of themes can be added to
this system without risking combinatorial
explosion.
 The ‘operational’ code is also much tighter and
more focused.
The Singleton
 The Factory and Abstract Factory handle
structural creation issues.
 They fix several aspects of bad design with
regards to creating objects.
 The Singleton is designed to increase data
consistency.
 One of the problems that must be managed
with object orientation is inter-object
communication.
The Singleton
 This is fine in most situations.
 However, when dealing with objects that
contain ‘live data’, it becomes problematic.
 Each object has its own copy of the data.
 It would be much better if all objects had
access to the same copy of the data.
 That is hard to manage effectively.
The Singleton
 The Singleton pattern resolves this by ensuring a
single interface to the creation of an object.
 Objects cannot be created with new, they must be
created through a method.
 This method is responsible for ensuring only one
live version of an object.
 If one exists, it sends that out.
 If it doesn’t, it creates it and then sends it out.
 The pattern is very simple.
 But offers great improvements in data consistency.
Summary
 Creational Patterns manage the complexity of
object instantiations.
 They make it easier to manage the combinatorial
explosion that comes along with certain kinds of
object creation schemes.
 The Factory allows for the creation of
properly configured objects.
 The Abstract Factory is a factory for factories.
 The Singleton ensures data consistency by
restricting instantiation of objects.
References
 Presentation session notes including link to this
session, will be available on
http://learningaboutfudge.blogspot.com
 All the source for this session is publically
available at:
https://github.com/SheepWorx/Training
 RSS Feed:
http://learningaboutfudge.blogspot.com/feeds/post
s/default?alt=rss
 Local Network: dmeyer-msharetrainingCode
Like a Ninja
 Source was compiled using Visual Studio 2012
 http://www.gofpatterns.com/
Thank You
Dr. Himanshu Hora
SRMS college of Engineering & Technology
Bareilly (UP) INDIA

Creational pattern

  • 1.
    Creational Patterns Dr. Himanshu Hora SRMScollege of Engineering & Technology Bareilly (UP) INDIA
  • 2.
    Contents  Introduction  Typesof Creational Pattern  Why use Creational Pattern  The Factory Pattern  The factory Design Pattern  Abstract factory  The Singleton  Summary  References
  • 3.
    Introduction  Creational designpatterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.
  • 4.
    Creational Patterns  Thereare three creational patterns  The Factory  The Abstract Factory  The Singleton
  • 5.
    Why Use ACreational Pattern?  Some situations are more complex than simple instantiation can handle.  Imagine for example you want to create an entirely ‘ skinnable’ look and feel for an application.  Some situations have complex consequences if objects aren’t instantiated in the right way or the right order.  Some situations require that only one object is ever created.
  • 6.
    The Factory Pattern The Factory is used to provide a consistent interface to setup properly configured objects.  It can be represented by a single class containing a single static method.  More complex factories exist, dealing with more complex situations.
  • 7.
    The Factory DesignPattern  Imagine a simple class hierarchy:
  • 8.
    The Factory DesignPattern  Now imagine you are creating a simple drawing package.  User selects a shape  User clicks on the screen  Application draws the shape.  This can all be hard-coded directly into an application.
  • 9.
    The Factory DesignPattern  Instead, we use a factory to generate specific objects, through the power of polymorphism.  Polymorphism is key to the way a Factory works.  The system that drives a factory is that all these shapes have a common parent class.  All we need is the Shape object that is represented by specific objects.
  • 10.
    Another Example  Let’ssay we have a file that we have created in our application.  We now want to export it to a different file format.  Each file format has its own peculiarities.  We could hard-code this into our application.
  • 11.
    The Factory DesignPattern  The Factory Pattern reduces hard-coded complexity.  The Factory Pattern properly devolves responsibility to individual objects.  However, the Factory pattern by itself is limited to certain simple contexts.
  • 12.
    The Abstract Factory The next level of abstraction is the Abstract Factory.  This is a Factory for factories.  Imagine here we have slightly more complicated situations.  Designing an interface that allows for different themes.  A file conversion application that must allow for different versions of different formats.
  • 13.
    The Abstract Factory We could handle these with a factory by itself.  This introduces the same combinatorial problems that the factory is designed to resolve.  A simple rule to remember is – coding combinations is usually bad design.  Bad design causes trouble later on.  When doing anything more substantial than simple ‘proof of concept’ applications.
  • 14.
    The Consequence  Entirelynew suites of themes can be added to this system without risking combinatorial explosion.  The ‘operational’ code is also much tighter and more focused.
  • 15.
    The Singleton  TheFactory and Abstract Factory handle structural creation issues.  They fix several aspects of bad design with regards to creating objects.  The Singleton is designed to increase data consistency.  One of the problems that must be managed with object orientation is inter-object communication.
  • 16.
    The Singleton  Thisis fine in most situations.  However, when dealing with objects that contain ‘live data’, it becomes problematic.  Each object has its own copy of the data.  It would be much better if all objects had access to the same copy of the data.  That is hard to manage effectively.
  • 17.
    The Singleton  TheSingleton pattern resolves this by ensuring a single interface to the creation of an object.  Objects cannot be created with new, they must be created through a method.  This method is responsible for ensuring only one live version of an object.  If one exists, it sends that out.  If it doesn’t, it creates it and then sends it out.  The pattern is very simple.  But offers great improvements in data consistency.
  • 18.
    Summary  Creational Patternsmanage the complexity of object instantiations.  They make it easier to manage the combinatorial explosion that comes along with certain kinds of object creation schemes.  The Factory allows for the creation of properly configured objects.  The Abstract Factory is a factory for factories.  The Singleton ensures data consistency by restricting instantiation of objects.
  • 19.
    References  Presentation sessionnotes including link to this session, will be available on http://learningaboutfudge.blogspot.com  All the source for this session is publically available at: https://github.com/SheepWorx/Training  RSS Feed: http://learningaboutfudge.blogspot.com/feeds/post s/default?alt=rss  Local Network: dmeyer-msharetrainingCode Like a Ninja  Source was compiled using Visual Studio 2012  http://www.gofpatterns.com/
  • 20.
    Thank You Dr. HimanshuHora SRMS college of Engineering & Technology Bareilly (UP) INDIA