The application of factory method pattern in C + + programming in the analysis of design patterns _c language

The factory method pattern differs from the simple factory pattern in that the factory method pattern places the object creation process into the lining class. This way the factory parent object, like the product parent object, can be an abstract class or interface that defines only the appropriate specification or operation, and does not involve specific creation or implementation details.
Its class diagram is as follows:

The instance code is:

#pragma once 
class iproduct 
{public 
: 
  iproduct (void); 
  Virtual ~iproduct (void); 
 
#pragma once 
#include "iproduct.h" 
class IPad: Public 
  iproduct 
{public 
: 
  ipad (void); 
  ~ipad (void); 
 
#pragma once 
#include "iproduct.h" 
class iphone: Public 
  iproduct 
{public 
: 
  iphone ( void); 
  ~iphone (void); 


#pragma once 
#include "IProduct.h" 
 
class ifactory 
{public 
: 
  ifactory (void); 
  Virtual ~ifactory (void); 
 
  Virtual iproduct* getproduct (); 
}; 
 
 
#pragma once 
#include "ifactory.h" 
class Ipadfactory: Public 
  ifactory 
{public 
: 
  Ipadfactory (void); 
  ~ipadfactory (void); 
 
  Virtual iproduct* getproduct (); 
}; 
 
 
#pragma once 
#include "ifactory.h" 
class Iphonefactory: Public 
  ifactory 
{public 
: 
  Iphonefactory (void); 
  ~iphonefactory (void); 
 
  Virtual iproduct* getproduct (); 
}; 

The key implementation:

#include "StdAfx.h" 
#include "IPadFactory.h" 
#include "IPad.h" 
 
ipadfactory::ipadfactory (void) 
{ 
} 
 
 
Ipadfactory::~ipadfactory (void) 
{ 
} 
 
iproduct* ipadfactory::getproduct () 
{return 
  new IPad () ; 
} 
 
 
#include "StdAfx.h" 
#include "IPhoneFactory.h" 
#include "IPhone.h" 
 
iphonefactory::iphonefactory ( void) 
{ 
} 
 
 
iphonefactory::~iphonefactory (void) 
{ 
} 
 
 
iproduct* iphonefactory:: GetProduct () 
{return 
  new IPhone (); 
} 

Call Mode:

#include "stdafx.h" 
#include "IFactory.h" 
#include "IPadFactory.h" 
#include "IPhoneFactory.h" 
#include "IProduct.h" 
 
 
int _tmain (int argc, _tchar* argv[]) 
{ 
  ifactory *FAC = new Ipadfactory (); 
  IProduct *pro = Fac->getproduct (); 
 
  FAC = new Iphonefactory (); 
  Pro = Fac->getproduct (); 
  return 0; 
} 

Application Scenario:
The database connection object within 1..net is the factory that produces the data command object. Each database connection object (inherited from IDbConnection) has an implementation of its own createcommand (defined in IDbCommand).
2..net inside the iterator, IEnumerable defines the interface of the iterator, that is, the factory method, every class that inherits from IEnumerable to implement GetEnumerator. You can refer to the GetEnumerator method of arraylist,string. They all inherit from IEnumerable.

Compare simple Factory mode with factory method mode:

1. Complexity of structure

From this point of view, it is obvious that the simple factory model should take advantage. The simple factory model only needs one factory class, and the factory method pattern's factory class increases with the number of product classes, which will undoubtedly make the number of classes more and more, thus increasing the complexity of the structure.

2. Complexity of code

Code complexity and structural complexity are a pair of contradictions, and since the simple factory pattern is relatively concise in structure, it is certainly more complex in code than in the factory approach model. The factory class of the simple factory pattern needs to add a lot of methods (or code) as the product class increases, while the factory method pattern completes a single task for each specific factory class, and the code is concise.

3. Client Programming Difficulty

Although the factory method pattern has introduced interfaces in the factory class structure to satisfy the OCP, it is necessary to instantiate the factory class in the client coding. The factory class of the simple factory pattern is a static class, and it is no doubt an attractive advantage to have no instantiation on the client side.

4. Difficulty in Management

This is a key issue.

Let's talk about expansion first. As we all know, the factory method pattern fully satisfies the OCP, that is, it has the very good expansibility. Does that mean that the simple factory model has no extensibility? The answer is in the negative. The simple factory model also has good scalability--the extension requires only a small amount of code to be modified (the code that modifies the factory class) to meet scalability requirements. Although this does not completely satisfy the OCP, but I think that do not need too rigidly adhere to the design theory.

Then we analyze it from a maintenance perspective. If a specific product class needs to be modified, it is likely that the corresponding factory class needs to be modified. When you need to modify multiple product classes at the same time, changes to the factory class can become quite cumbersome (the problem is already a question). Instead of having these problems in a simple factory, when multiple product classes need to be modified, the simple factory model still needs only to modify the only factory class (no matter how it can be changed to meet the requirements). Big deal to rewrite this class).

From the above analysis, I think the simple factory model better use more convenient. Of course, this is only the author's personal opinion, after all, the factory method model is more "advanced" than the simple factory model. But sometimes too advanced things are not suitable for themselves, this is a matter of opinion.