27-10-2012, 04:57 PM
Creational Patterns
creational patterns.pdf (Size: 423.23 KB / Downloads: 78)
Introduction to Creational Patterns
These patterns support one of the most common tasks in object-oriented programming—
the creation of objects in a system. Most OO systems of any complexity
require many objects to be instantiated over time, and these patterns
support the creation process by helping to provide the following capabilities:
• 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 following patterns are discussed in this chapter:
• Abstract Factory – To provide a contract for creating families of related
or dependent objects without having to specify their concrete classes.
• Builder – To simplify complex object creation by defining a class whose
purpose is to build instances of another class. The Builder produces one
main product, such that there might be more than one class in the product,
but there is always one main class.
• Factory Method – To define a standard method to create an object, apart
from a constructor, but the decision of what kind of an object to create is
left to subclasses.
• Prototype – To make dynamic creation easier by defining classes whose
objects can create duplicates of themselves.
• Singleton – To have only one instance of this class in the system, while
allowing other classes to get access to this instance.
Of these patterns, the Abstract Factory and Factory Method are explicitly
based on the concept of defining flexible object creation; they assume that the
classes or interfaces to be created will be extended in an implementing system.
As a result, these two patterns are frequently combined with other creational
patterns.
Introduction
Suppose you plan to manage address and telephone information as part of a
personal information manager (PIM) application. The PIM will act as a combination
address book, personal planner, and appointment and contact manager,
and will use the address and phone number data extensively.
You can initially produce classes to represent your address and telephone
number data. Code these classes so that they store the relevant information and
enforce business rules about their format. For example, all phone numbers in
North America are limited to ten digits and the postal code must be in a particular
format.
Shortly after coding your classes, you realize that you have to manage
address and phone information for another country, such as the Netherlands.
The Netherlands has different rules governing what constitutes a valid phone
number and address, so you modify your logic in the
Address
and
PhoneNumber
classes to take the new country into account.
Now, as your personal network expands, you need to manage information
from another foreign country... and another... and another. With each additional
set of business rules, the base
Address
and
PhoneNumber
classes become even
more bloated with code and even more difficult to manage. What's more, this
code is brittle—with every new country added, you need to modify and recompile
the classes to manage contact information.
It’s better to flexibly add these paired classes to the system; to take the general
rules that apply to address and phone number data, and allow any number
of possible foreign variations to be “loaded” into a system.
Applicability
Use the Abstract Factory pattern when:
• The client should be independent of how the products are created.
• The application should be configured with one of multiple families of
products.
• Objects need to be created as a set, in order to be compatible.
• You want to provide a collection of classes and you want to reveal just
their contracts and their relationships, not their implementations.
Description
Sometimes an application needs to use a variety of different resources or
operating environments. Some common examples include:
• Windowing (an application’s GUI)
• A file system
• Communication with other applications or systems
In this sort of application you want to make the application flexible enough
to use a variety of these resources without having to recode the application each
time a new resource is introduced.
An effective way to solve this problem is to define a generic resource creator,
the Abstract Factory. The factory has one or more create methods, which
can be called to produce generic resources or abstract products.
Java (“Java technology”) runs on many platforms, each with many different
implementations of a file system or windowing. The solution Java has taken is
to abstract the concepts of files and windowing and not show the concrete
implementation. You can develop the application using the generic capabilities
of the resources as though they represented real functionality.
During runtime,
ConcreteFactories
and
ConcreteProducts
are created
and used by the application. The concrete classes conform to the contract
defined by the
AbstractFactory
and
AbstractProducts
, so the concrete
classes can be directly used, without being recoded or recompiled.