prior to reading some information about the factory model and the abstract factory model, the characteristics and differences between the factory model and the abstract factory model were understood. Today came back to see the notes I wrote before, and began to confuse, the following some of their own confusion and ideas recorded.
1. Where is the simple factory model used? Cross-platform issues arise in many open source libraries. Suppose you have a window module (that is, a DLL) that provides the basic functions of the window, such as setting the caption, setting the window background color, and so on. In different platforms, the creation window needs to call different APIs, such as the Windows platform, the creation window can call MFC or Windows API, the Linux Platform Creation window needs to call X11 's API, so different platforms need different window classes to implement. With the base class window, subclass Win_window, Linux_window, Android_window, the code is as follows:
Only the interface of the abstract class window is defined in Window.h (this is used as an example to illustrate the usage environment of the simple factory pattern, so it simply defines three interfaces without the implementation of the functionality) and the Create_window function.
Window.hclass window{public : virtual ~window () {};//must be a virtual function public : virtual void Set_titile (const char* title_) = 0;//pure virtual function virtual void set_background_color (int r_, int g_, int b_, int a_) = 0; virtual void set_size (int width_, int height_) = 0;}; window* Create_window ();
the specific subclasses Win_window, Linux_window, Android_window, and function Create_window are defined and implemented in Window.cpp. The code is as follows:
Window.cppclass linux_window:public window{public : ~win_window () {} public : void Set_title ( Const char* title_) {\ \ \ \ \ \ \ \ Temporarily does not implement function} void Set_background_color (int r_, int g_, int b_, int a_) {\ \ \ \ \ \ Temporarily does not implement function} void Set_size (int width_, int height_) {\ \ Temporarily does not implement the function}}; Class Android_window:public window{public : ~win_window () {} public : void Set_title (const char* title_) {\ \ \ \ \ \ \ Temporarily does not implement function} void Set_background_color (int r_, int g_, int b_, int a_) {\ \ \ \ \ \ \ Temporarily does not implement function} void set_size (int width_, int height_) {\ \ \ \ \ \ \ \}};window* Create_window () { window* wind = NULL; if (System_str = = "Win32") wind = new Win_window (); else if (system_str = = "Linux") wind = new Linux_window (); else if (System_str = = "Android") wind = new Android_window (); else wind = NULL; return wind;}
The above function Create_window generates different window classes based on different systems, making external calls without having to consider cross-platform issues, and on any platform there is only one copy of the code for the external call to create the window. Please note that while we are looking at the design pattern book, the simple Factory mode is generally a class, and I wrote a function saying that using the simple Factory mode, is it wrong? There is no error, design model to provide us with a way of thinking, in the learning design mode, we should grasp the focus, learn to adapt, not too much attention to the rules.
Some people here may ask: if you do not define the Create_window function, it is not possible to put the code of the Create_window function in the place where the window is created externally.
Yes, that's OK. However, using the Create_window function to encapsulate the process of creating a window class is compared to using Create_window, which has two advantages: (1) Call the Create_window function only, the code is concise and the logic is clear; (2) If you're careful, you'll find that I only defined the window abstract class and the Create_window function in the window.h header file, and did not declare the other three subclasses, but instead declared and implemented the three subclasses in the Window.cpp file. This makes the three subclasses transparent to the outside, without knowing that there are three subclasses at all.
Here you may ask, what are the benefits of three sub-classes being transparent to the outside? Suppose such a situation: if I change a window module, this window module also defines the Windows abstract class and the Create_window, but the subclass name and the previous window module are different, this time can see the benefits of abstract class to external transparency. Because the Create_window function was used previously by external calls, the window module changed, but as long as the Windows abstract class and Create_window did not change, the external window module could be used without changing any code.
2. Where will the factory model and abstract factory model be used?
3. Why use Factory mode and abstract Factory mode?
Questions 2 and 3 can actually find the answer in question 1. Both the Factory mode and the abstract factory pattern are used to isolate the object's creation process, making the concrete class transparent to the external call, i.e. the outside does not know the existence of subclasses. In this way, after modifying the sub-class, the external can not be modified or only make minimal changes.
The above content is purely own some understanding, if is wrong, welcome everybody to correct.
Some reflections on the factory model
