Design Pattern [1] -- factory pattern

The role of design patterns in the design and development of object-oriented systems is like the role of data structures in process-oriented development. The importance and necessity of design patterns naturally do not need to be described in detail. However, the process of learning the design pattern is painful. From reading the Bible of the design pattern-GoF's design pattern: the basis for reusable object-oriented software, there is no clue about the boring, boring, and confusing process, one day there was a sudden epiphany: I knew why when I went to implement the GoF's 23 modes, one day, I was miserable due to design reasons in my own system. I suddenly realized that one of the design patterns could solve the problem, come to your own design of the elegant system, and think about it: until you finally explain the design pattern to others, others ask you about the design pattern, and discuss the design pattern with others.

I think the process of learning the design model should be an iterative process. I have always mastered and understood things without having to pursue them all over again (it is impossible in many cases ), I like to use an iterative idea to guide my learning process. Reading and thinking are not understandable. You can read and think over and over again, I think such a process is suitable for learning a technology and knowledge from us rather than having a very unified time (sometimes it is boring and depressing ). GoF also mentioned in "design patterns" that, if you are not an experienced object-oriented designer, we recommend that you get started with the simplest and most commonly used design patterns, for example, AbstractFactory mode, Adapater mode, Composite mode, Decorator mode, Factory mode, Observer mode, Strategy mode, and Template mode. My feeling is that the same is true. At least the models listed by GoF are all useful in development and design. If you need to add a few patterns that I think will be useful in development: singleton mode, Fa C ade mode, and Bridge mode.

In order to sum up my understanding in the process of learning the design model, I personally learned from the good chapters written in the books and some of the more refined documents summarized on the Internet, add some of your ideas and chat in the form of a blog to record --

The factory mode is a creation mode, which can be roughly divided into three types: simple factory mode, factory method mode, and abstract factory mode. It sounds like a factory model. Next, we will introduce the simple factory model one by one. Its main feature is to make judgments in the factory class to create corresponding products. When a new product is added, You need to modify the factory class. A little abstract. Let's take an example. There is a manufacturer that produces processor cores. It has only one factory and can produce two types of processor cores. What kind of processor cores the customer needs must explicitly inform the production plant. An implementation scheme is provided below.

1 enum CTYPE {COREA, COREB}; 2 class SingleCore 3 {4 public: 5 virtual void Show () = 0; 6}; 7 // single core A 8 class SingleCoreA: public SingleCore 9 {10 public: 11 void Show () {cout <"SingleCore A" <endl ;}12}; 13 // Single-core B 14 class SingleCoreB: public SingleCore 15 {16 public: 17 void Show () {cout <"SingleCore B" <endl ;}18}; 19 // unique factory, two types of processor cores can be produced. Internally, 20 class Factory 21 {22 public: 23 SingleCore * CreateSingleCore (enum CTYPE ctype) 24 {25 if (ctype = COREA) can be determined) // factory internal Judgment 26 return new SingleCoreA (); // production core A 27 else if (ctype = COREB) 28 return new SingleCoreB (); // production core B 29 else 30 return NULL; 31} 32 };

The main disadvantage of this design has been mentioned before, that is, to add a new core type, you need to modify the factory class. This violates the open and closed principle: software entities (classes, modules, and functions) can be expanded, but cannot be modified. As a result, the factory method model emerged. The so-called factory method mode refers to defining an interface for creating objects, so that the subclass decides which class to instantiate. Factory Method delays the instantiation of a class to its subclass.

It sounds very abstract. I will explain it in the example just now. The processor core producer made a lot of money, so he decided to set up another factory dedicated to produce the single-core number B, and the original factory dedicated to producing the single-core number. In this case, the customer needs to find the factory. For example, if the-type core is required, the customer needs Factory A; otherwise, the customer needs factory B, you no longer need to tell the factory what type of processor core is required. An implementation scheme is provided below.

1 class SingleCore 2 {3 public: 4 virtual void Show () = 0; 5}; 6 // single core A 7 class SingleCoreA: public SingleCore 8 {9 public: 10 void Show () {cout <"SingleCore A" <endl ;}11}; 12 // Single-core B 13 class SingleCoreB: public SingleCore 14 {15 public: 16 void Show () {cout <"SingleCore B" <endl ;}17}; 18 class Factory 19 {20 public: 21 virtual SingleCore * CreateSingleCore () = 0; 22}; 23 // Factory 24 class FactoryA producing A core: public Factory 25 {26 public: 27 SingleCoreA * CreateSingleCore () {return new SingleCoreA () ;}28 }; 29 // Factory producing B-core 30 class FactoryB: public Factory 31 {32 public: 33 SingleCoreB * CreateSingleCore () {return new SingleCoreB () ;}34 };

The factory method model also has disadvantages. Each time a product is added, a factory with an object needs to be added. If the company is developing rapidly and has launched many new processor cores, it is necessary to set up a new factory. In the implementation of C ++, the factory classes must be defined one by one. Obviously, the factory method mode requires more class definitions than the simple factory mode.

Now that we have a simple factory model and a factory method model, why do we need an abstract factory model? What does it do? For example, the company's technological advances can not only produce single-core processors, but also multi-core processors. At present, the simple factory model and the factory method model are beyond reach. The abstract factory model was launched. It is defined to provide an interface for creating a series of related or mutually dependent objects without specifying their specific classes. Specifically, this company opened two factories, one dedicated to producing a-Type Single-core processor, and the other dedicated to producing a-Type Single-core processor, the following is the implementation code.

1 // Single-core 2 class SingleCore 3 {4 public: 5 virtual void Show () = 0; 6}; 7 class SingleCoreA: public SingleCore 8 {9 public: 10 void Show () {cout <"Single Core A" <endl ;}11}; 12 class SingleCoreB: public SingleCore 13 {14 public: 15 void Show () {cout <"Single Core B" <endl ;}16}; 17 // multi-Core 18 class MultiCore 19 {20 public: 21 virtual void Show () = 0; 22}; 23 class MultiCoreA: public MultiCore 24 {25 public: 26 void Show () {cout <"Multi Core A" <endl ;}27 28 }; 29 class MultiCoreB: public MultiCore 30 {31 public: 32 void Show () {cout <"Multi Core B" <endl ;}33 }; 34 // factory 35 class CoreFactory 36 {37 public: 38 virtual SingleCore * CreateSingleCore () = 0; 39 virtual MultiCore * CreateMultiCore () = 0; 40 }; 41 // Factory A, specially used to produce the 42 class FactoryA: public CoreFactory 43 {44 public: 45 SingleCore * CreateSingleCore () {return new SingleCoreA ();} 46 MultiCore * CreateMultiCore () {return new MultiCoreA () ;}47}; 48 // factory B, specially used to produce type B processor 49 class FactoryB: public CoreFactory 50 {51 public: 52 SingleCore * CreateSingleCore () {return new SingleCoreB ();} 53 MultiCore * CreateMultiCore () {return new MultiCoreB () ;}54 };

At this point, the factory model has been introduced, and the UML diagrams of the three factory models are provided below to deepen the impression.

UML diagram of simple factory mode:

UML diagram of the factory method:

Abstract The UML diagram of the factory model:

 

Original article: http://blog.csdn.net/wuzhekai1985