Implementation of

Abstract Factory (Creational)

Design Pattern
 INTRODUCTION
Design patterns that describe simple and elegant solutions to
specific problems in object-oriented software design. A design
pattern is a general repeatable solution to a commonly occurring
problem in software design. Design patterns make it easier to reuse
successful designs and architectures.
In general, a pattern has four essential elements:
1. The pattern name is a handle we can use to describe a design
problem, its solutions, and consequences in a word or two.
2. The problem describes when to apply the pattern. It explains
the problem and its context.
3. The solution describes the elements that make up the design,
their relationships, responsibilities, and collaborations.
4. The consequences are the results and trade-offs of applying
the pattern. Consequences of a pattern include its impact on a
system's flexibility, extensibility, or portability. Listing these
consequences explicitly helps you understand and evaluate
them.

Benefits of Design pattern:

 Speed up the development
 Providing tested and proven development
 Easier to use or reuse
 Cost effective

1
Types of Design Pattern
1. Creational design patterns
This design patterns is help to make a system independent of how its
objects are created, composed, and represented.
 Abstract Factory
 Builder
 Factory Method
 Object Pool
 Prototype
 Singleton

2. Structural design patterns

Structural patterns are concerned with how classes and objects are
composed to form larger structures. Structural class patterns use
inheritance to compose interfaces or implementations. Structural object-
patterns define ways to compose objects to obtain new functionality.
 Adapter
 Bridge
 Composite
 Decorator
 Façade
 Flyweight
 Private Class Data
 Proxy

3. Behavioral design patterns

This design patterns is describe not just patterns of objects or classes but
also the patterns of communication between them.
 Chain of responsibility
 Command
 Interpreter
 Iterator
 Mediator
 Observer

2
Abstract Factory Design Pattern
Intent

 Provide an interface for creating families of related or dependent objects

without specifying their concrete classes.
 A hierarchy that encapsulates: many possible "platforms", and the
construction of a suite of "products"

Problem

If an application is to be portable, it needs to encapsulate platform dependencies.

These "platforms" might include: windowing system, operating system, database,
etc. Too often, this encapsulation is not engineered in advance, and lots of #ifdef
case statements with options for all currently supported platforms begin to
procreate like rabbits throughout the code.

Motivation

Provide a level of indirection that abstracts the creation of families of related or

dependent objects without directly specifying their concrete classes. The "factory"
object has the responsibility for providing creation services for the entire
platform family. Clients never create platform objects directly, they ask the
factory to do that for them.

This mechanism makes exchanging product families easy because the specific
class of the factory object appears only once in the application - where it is
instantiated. The application can wholesale replace the entire family of products
simply by instantiating a different concrete instance of the abstract factory.

Because the service provided by the factory object is so pervasive, it is routinely

implemented as a Singleton.

Applicability
 It isolates concrete classes. The Abstract Factory pattern helps you control
the classes of objects that an application creates. Because a factory
encapsulates the responsibility and the process of creating product objects,
it isolates clients from implementation classes. Clients manipulate
instances through their abstract interfaces. Product class names are
isolated in the implementation of the concrete factory; they do not appear
in client code.
 It makes exchanging product families easy. The class of a concrete factory
appears only once in an application---that is, where it's instantiated. This
makes it easy to change the concrete factory an application uses. It can
use different product configurations simply by changing the concrete

3
 factory. Because an abstract factory creates a complete family of products,
the whole product family changes at once. In our user interface example,
we can switch from Motif widgets to Presentation Manager widgets simply
by switching the corresponding factory objects and recreating the
interface.
 It promotes consistency among products. When product objects in a family
are designed to work together, it's important that an application use
objects from only one family at a time. AbstractFactory makes this easy to
enforce.
 Factory methods eliminate the need to bind application-specific classes
into your code.
 The code only deals with the product interfaces; therefore, it can work
with any user-defined concrete product classes.

Structure

4
Class Diagram
In Abstract Factory pattern an interface is responsible for creating a factory of
related objects without explicitly specifying their classes. Each generated factory
can give the objects as per the Factory pattern. We are going to create a Shape
and Color interfaces and concrete classes implementing these interfaces. We
create an abstract factory class AbstractFactory as next step. Factory classes
ShapeFactory and ColorFactory are defined where each factory extends
AbstractFactory. A factory creator/generator class FactoryProducer is created.