Factory mode

　　1) In order to improve the 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. Bring here two questions 1) the client programmer must know the name of the actual problem subclass (when the system is complex, named would be a very bad deal, in order to deal with possible name conflict, some names may not have a very good readability 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.

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

　　　　　　　　　　　　　　　　　　　　　　figure 1

　　Factory mode is 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 is a schematic view of a second case of Factory:

　　　　　　　　　　　　　　　　　　　　　　figure 2

　　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.

Product.h

 1 #ifndef _PRODUCT_H_ 
 2 #define _PRODUCT_H_
 3 class Product { 
 4 public: 
 5     virtual ~Product() =0;
 6 protected: 
 7     Product();
 8 private:
 9 };
10 class ConcreteProduct:public Product 
11 { 
12 public: 
13     ~ConcreteProduct();
14     ConcreteProduct(); 
15 protected:
16 
17 private:
18 };
19 #endif //~_PRODUCT_H_

Product.cpp

1 #include "Product.h"
2 #include<iostream> 
3 using namespace std;
4 Product::Product() { cout<<"Product...."<<endl; }
5 Product::~Product() {
6     cout<<"~Product...."<<endl;
7 }
8 ConcreteProduct::ConcreteProduct() { cout<<"ConcreteProduct...."<<endl; }
9 ConcreteProduct::~ConcreteProduct() {}

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_

Factory.cpp

#include "Factory.h"
#include "Product.h"
#include <iostream> 
using namespace std;
Factory::Factory() {
    cout<<"Factory....."<<endl;
}
Factory::~Factory() {
    cout<<"~Factory....."<<endl;
}
ConcreteFactory::ConcreteFactory() { cout<<"ConcreteFactory....."<<endl; }
ConcreteFactory::~ConcreteFactory() {
}
Product* ConcreteFactory::CreateProduct() { return new ConcreteProduct(); }

main.cpp

 1 #include "Factory.h" 
 2 #include "Product.h"
 3 #include <iostream> 
 4 using namespace std;
 5 int main(int argc,char* argv[]) { 
 6     Factory* fac = new ConcreteFactory();
 7 
 8     Product* p = fac->CreateProduct();
 9 
10     return 0; 
11 }

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.

Guess you like