Design Patterns 1/23 Factory mode

Author K_Eckel

Original Address http://www.mscenter.edu.cn/blog/k_eckel

Problems
often encountered the following two problems in object-oriented system design:
1) In order to improve cohesion (Cohesion) and loose coupling (Coupling), we often some abstract class public interface to form an abstract base class or interface . In this way we can declare a pointer to point to the actual base class subclass implemented, achieve the purpose of polymorphism. One problem here is prone to the n number of sub-class inherits from the abstract base class, we had to use to place each subclass on the preparation of such new ×××; code.

Two problems here

1) client programmer must know the name of the actual subclass (when the system is complex, naming issue would be a very bad deal, in order to deal with possible name conflict, some names may not be very readable and memorability, on different programmers aside the strange personal preference.),

2) the expansion and maintenance programs is becoming increasingly difficult.

2) Another case is the parent class does not know exactly which a concrete subclass to instantiate. The meaning here is: Suppose we want to use in class A to class B, B is an abstract parent class, particularly in A does not know that to instantiate a subclass of B, but a subclass of class A in D It is to know. In A, we have no way to directly use the new ××× similar statement, because do not know what ××× Yes.
Two or more leads to two problems will Factory pattern most important functions:
creating an object 1) the definition of the interface, the package object creation;
2) such that the specific work to delay class subclasses.

Mode selection
we usually use Factory mode to solve two problems given above. In the first issue, we often create objects that declare an interface, and encapsulates the process of creating an object. Factory here is similar to a factory (production target) in the true sense. In the second question, we need to create an object to provide an object interface, and provides specific implementation in the subclass (because only in subclasses decide which class to instantiate in the end).
Factory schematic structure in the case of the first is:

Figure 1: Factory mode structure diagram

Figure 1 so the Factory pattern often used in system development, but this is not the greatest power lies Factory mode (because it can solve this problem through other means). Factory model not only provides an interface to create an object, which is the most important examples of delayed (second problem) subclass, the following case is a schematic view of a Factory of:

FIG 2: Factory mode structure diagram

Figure 2 application key mode Factory is not just to create the package object, but should create an object into subclasses implement: Factory in just provides an interface object creation, in fact, now on the sub-Factory ConcreteFactory performed in class. This is the difference between the 2 and 1 lies.

Achieve
complete code examples (code)
to achieve Factory model is relatively simple, here for the convenience of beginners learning and reference, gives the full implementation code (all code using C ++ implementation, and VC test run under 6.0).

代码片断1：Product.h
//Product.h
#ifndef _PRODUCT_H_
#define _PRODUCT_H_

class Product
{
public:
	virtual ~Product() = 0;
	protected:
	Product();
private:
};

class ConcreteProduct:public Product
{
public:
	~ConcreteProduct();
	ConcreteProduct();
protected:
private:
};

#endif //~_PRODUCT_H_

代码片断2：Product.cpp
//Product.cpp
#include "Product.h"
#include <iostream>
using namespace std;

Product::Product()
{
}

Product::~Product()
{
}

ConcreteProduct::ConcreteProduct()
{
	cout<<"ConcreteProduct...."<<endl;
}

ConcreteProduct::~ConcreteProduct()
{
}

代码片断3：Factory.h
//Factory.h
#ifndef _FACTORY_H_
#define _FACTORY_H_
class Product;

class Factory
{
public:
	virtual ~Factory() = 0;
	virtual Product* CreateProduct() = 0;
	protected:
	Factory();
private:
};

class ConcreteFactory:public Factory
{
public:
	~ConcreteFactory();
	ConcreteFactory();
	Product* CreateProduct();
protected:
private:
};

#endif //~_FACTORY_H_

代码片断4： Factory.cpp
//Factory.cpp
#include "Factory.h"
#include "Product.h"
#include <iostream>
using namespace std;

Factory::Factory()
{
}

Factory::~Factory()
{
}

ConcreteFactory::ConcreteFactory()
{
	cout<<"ConcreteFactory....."<<endl;
}

ConcreteFactory::~ConcreteFactory()
{
}

Product* ConcreteFactory::CreateProduct()
{
	return new ConcreteProduct();
}

代码片断5：main.cpp
//main.cpp
#include "Factory.h"
#include "Product.h"
#include <iostream>
using namespace std;

int main(int argc,char* argv[])
{
	Factory* fac = new ConcreteFactory();
	Product* p = fac->CreateProduct();
	return 0;
}

Code Description
sample code given is the parent class solution Factory pattern does not know which specific subclass specific problem to be instantiated, as for the problem provides an interface for creating an object that can be attached by the Factory corresponding Create creation e.g. *** Product () can be. For details, please participate in the discussion.

Discussed
Factory mode in the actual development is widely used, object-oriented systems are often faced with the problem of object creation: To create a class that is too much. And the interface package (the first function) to create an object Factory provided, and it will defer to the instantiation of a class subclasses (second function) are partially solve the real problems. A simple example is the semantic analysis procedure I developed VisualCMCS open system, due to the configuration for each nonterminal symbol in a grammar-based processing, thus creating the process very large object, using model systems readability Factory elegant and maintenance have become many.

Factory mode also brings at least the following two questions:

1) If an instance of a function body ConcreteProduct each specific class, then we may have to add a method in the system to deal with this new ConcreteProduct, this Factory interface can always refused to close (Close). Of course, we can create a subclass Factory to achieve this through a multi-state, but it is also to create a new class as a cost.

2) In the implementation, we can, that is, to FactoryMethod () to pass a parameter by parameter chemical method is used to determine exactly which create a specific Product (in fact the author in VisualCMCS also doing just that). Of course, can also be avoided by templating subclass 1) to create a sub-class, which is to be specific Product class as a template parameter, it is also very simple to implement.

As can be seen, the Factory pattern to create objects give developers a good implementation strategy, but the Factory pattern confined to a class of (Product is a class that is, have a common base class), if we want to different classes of class provides an interface object created, then use the AbstractFactory.

Reproduced in: https: //www.cnblogs.com/caleb/archive/2011/09/07/2169486.html

Design Patterns 1/23 Factory mode

Guess you like