次の方法で共有

Software Design Patterns - Creational Patterns

  • [アーティクル]

This happens to be the first of my articles on Software Design Patterns. I will present some basics followed by implementation of the pattern.

These patterns help make a system independent of how its objects are created, composed and represented.
A class creational pattern uses inheritance to vary the class that’s instantiated, whereas the object creational pattern will delegate instantiation to another object.

In creational patterns emphasis shifts away from hard coding a fixed set of behaviors towards defining a smaller set of fundamental behaviors that can be composed into any number of more complex ones. Thus object composition becomes more important than class inheritance.
Some widely used patterns in this category are:

Abstract Factory
- The main purpose is to create objects for the product class.

 - The break-up of classes involved is as follows:
> You need an abstract factory class which acts as a base to some concrete classes.
> You need an abstract product/entity class which will act as a base class for some fixed number of concrete product classes.
> A client, which always uses the interfaces declared by the abstract factory and product classes.
> The factory class is not abstract; it in fact uses the Singleton pattern to create only 1 instance. It is used by the product classes to create new instances.

 - You can use this pattern in the following cases:
> A system is independent in terms of how its products are created, composed and represented.
> You want to provide a class library of things, and you don’t want to reveal the implementations but interfaces.
> The number of products is defined.

 - Advantages:
> Concrete classes are isolated. Product class names are isolated in the implementation of the concrete factory.
> Product families can be changed easily.
> Promotes consistency among products.

 - Disadvantages:
> Supporting new kinds of products is difficult. It requires you to change the abstract and concrete factory classes at number of places.

Factory
- This pattern defines an interface for creating an object, but let subclasses decide which class to instantiate.

 - The break-up of the classes involved is as follows:
> You need a Product and a Creator
> Concrete classes for Product and Creator.
> Creator relies on its subclasses to define factory method so that it returns an instance of the appropriate Concrete Product.

 - The following happens:
> You may create multiple Creator classes, and multiple Product classes.
> Each Creator has something like a Create() function that creates one/more Products.
> From a client, you create an array of Creator base abstract class. This array can have objects from any of the inherited Creator classes.
> The inherited Creator classes then create one/more Products for the client.

Builder
- This pattern is useful when you want to separate the construction of a complex object from its representation. This enables the same construction process to create different representations.
- It involves a Builder and a Director.
- Use this pattern if:
> You need to keep the algorithm of creating a complex object separate from the parts that make it up.
> The construction process must allow different representations for the object that’s constructed.

 - The break-up of the classes involved are as follows:
> There is an abstract builder class for creating parts of a product object.
> You need a Concrete Builder class to construct and assemble parts of the product by implementing Builder.
> A Director class that constructs an object by using the Builder.
> The Product classes that represent the complex object under construction. They do not require an Abstract base class as their implementations have to be very different.

 - The following happens:
> A client creates the Director object and configures it with the desired Builder object.
> Director notifies the Builder to build a Product. Builder then adds parts to the Product.
> The client retrieves the Product from the builder.

 - Advantages:
> Director has no direct interaction with the Product so you can easily change/modify them.
> It isolates the code for construction and representation.
> This pattern constructs products step by step under Director’s control.

Comments