The document introduces creational design patterns, which manage object creation and provide a cohesive interface for complex situations. It discusses three main patterns: the factory, abstract factory, and singleton, detailing their uses and implementations. These patterns help alleviate issues like combinatorial explosion and ensure data consistency in object-oriented programming.

1. Creational
Patterns
Michael Heron

2. Introduction
 Today we introduce a small suite of design
patterns that fall under the family known as
creational.
 They are used to create objects, or manage the
object creation process in some way.
 For some applications and contexts, it’s not
appropriate or useful to simply instantiate
objects with new whenever you want to.
 Creational patterns provide a cohesive
interface when these circumstances arise.

3. Creational Patterns
 There are three creational patterns we will
discuss during this lecture.
 The Factory
 The Abstract Factory
 The Singleton
 We will also discuss specific examples of
use for each.

4. 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.

5. The Factory Pattern
 The Factory is used to provide a consistent
interface to setup properly configured
objects.
 You pass in some configuration details
 Out comes a properly configured object.
 At its simplest, it can be represented by a
single class containing a single static method.
 More complex factories exist, dealing with more
complex situations.

6. The Factory Design Pattern
 Imagine a class:

7. The Factory Design Pattern
 Then imagine a simple class hierarchy:

8. 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.
 This suffers from scale and readability issues.

9. 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.
 Thus, all we need is the Shape object that is
represented by specific objects.
 The objects themselves manage the
complexity of the drawing process.

10. The Factory Design Pattern
public class ShapeFactory {
public Shape getShape (String shape, int x, int y, int len, int ht, Color col) {
Shape temp = null;
if (shape.equals ("Circle")) {
temp = new Circle (x, y, len, ht);
}
else if (shape.equals ("Rectangle")) {
temp = new Rectangle (x, y, len, ht);
}
else if (shape.equals ("Face")) {
temp = new Face (x, y, len, ht);
}
temp.setDrawingColor (col);
return temp;
}
}

11. 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…
 … or we could use a factory to get the
object that can handle the export.

12. The Factory Design Pattern
public String doConversion (string format, string file) {
ConversionObject c;
c = ConversionFactory.getConversionObject (format);
file = c.covert (file);
return file;
}
myFile = doConversion (“unicode”, myFile);
myFile = doConversion (“ascii”, myFile);

13. The Factory Design Pattern
 The Factory Pattern reduces hard-coded
complexity.
 We don’t need to worry about combinatorial
explosion.
 The Factory Pattern properly devolves responsibility
to individual objects.
 We don’t have a draw method in our application,
we have a draw method in each specific shape.
 However, the Factory pattern by itself is limited to
certain simple contexts.
 For more complicated situations, we need more.

14. 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.

15. 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.

16. Bad Design
public Component getComponent (String type, String theme) {
Component guiComponent;
if (theme.equals ("swing")) {
if (type.equals ("button")) {
guiComponent = new JButton ();
}
else if (type.equals ("label")) {
guiComponent = new JLabel();
}
}
else if (theme.equals ("awt")) {
if (type.equals ("button")) {
guiComponent = new Button ();
}
else if (type.equals ("label")) {
guiComponent = new Label();
}
}
return guiComponent;
}

17. Good Design
 Good Design in this case involves creating
one factory that creates the right kind of
factory for the components.
 We have a SwingFactory and an AwtFactory.
 That factory generates the appropriate
components.
 This requires a somewhat more complicated
class structure.
 Each Factory must inherit from a common base

18. Good Design

19. Abstract Factory
Implementation
public class AbstractFactory {
public static Factory getFactory (string look) {
Factory temp;
if (look.equals ("windows")) {
temp = new WindowsFactory();
}
else if (look.equals ("swing")) {
temp = new SwingFactory();
}
else if (look.equals ("macintosh")) {
temp = new MacintoshFactory();
}
return temp;
}
}

20. Factory Implementation
public class SwingFactory extends Factory {
public GuiWidget getWidget (string type) {
SwingWidget temp = null;
if (type.equals ("button")) {
temp = new JButton();
}
else if (type.equals ("scrollbar")) {
temp = new JScrollbar();
}
return temp;
}
abstract class Factory {
abstract GuiWidget getWidget (String type);
}

21. 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.
Factory myFactory = AbstractFactory.getFactory ("swing");
GUIWidget myWidget = myFactory.getWidget ("button");

22. 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 way this is often done is by giving each
object its own instantiations of other objects.

23. 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.
 That’s bad voodoo, man.
 It would be much better if all objects had
access to the same copy of the data.
 That is hard to manage effectively.

24. 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.

25. The Singleton
public class Singleton {
private Singleton keepItSafe;
private Singleton() {
// Private constructor prevents external instantiation.
}
public static Singleton getInstance() {
if (keepItSafe == null) {
keepItSafe = new Singleton();
}
return keepItSafe;
}
}

26. The Singleton
 There are various other ways of implementing
the singleton.
 As there are other ways of implementing any
design pattern.
 One way is to keep a static counter of how
many instances have been created.
 For singleton, if the counter is 1 you don’t allow
new objects.
 The Multiton pattern keeps an internal hash
map of instances.
 Allowing only newly keyed instantiations.

27. 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.