Simple factory mode is simple, but there is a very serious problem.When a new product needs to be introduced in the system, because the static factory method creates different products through different input parameters, the source code of the factory class must be modified, which will violate the "open and closed principle ", how to add new products without affecting existing code?The factory method model came into being. This article will introduce the second factory model-the factory method model.
1. Logger Design
Sunny software company wants to develop a logger for system operation, which can store system operation logs in multiple ways, such as through file records or database records, you can flexibly change the logging mode by modifying the configuration file. When designing various types of log recorders, sunny developers found that they needed to initialize the logger. The initialization parameter setting process was complicated, in addition, some parameters are strictly ordered; otherwise, record failures may occur. How to encapsulate the recorder initialization process and ensure the flexibility of switching among multiple recorders is a challenge for sunny developers. |
By analyzing this requirement, sunny developers found that the logger has two design points:
(1) the initialization process of the logger needs to be encapsulated, which is complex. For example, to initialize other related classes, you may need to read the configuration file (such as connecting to the database or creating a file ), the code is long. If you write them all in the constructor, the constructor will be large, which is not conducive to code modification and maintenance;
(2) You may need to change the logging method. In the client code, you need to provide a flexible way to select a logger, try to replace or add the logging method without modifying the source code.
Sunny developers initially designed the logging recorder in the simple factory mode. The initial structure 1 is shown in:
Figure 1 structure of the Logger Based on the simple factory Model
In Figure 1, loggerfactory acts as the factory for creating a logger and provides the factory method createlogger () for creating a logger. logger is an abstract logger interface and its subclass is a specific logger. The factory-class loggerfactory code snippets are as follows:
// Logger factory class loggerfactory {// static factory method public static logger createlogger (string ARGs) {If (ARGs. equalsignorecase ("DB") {// connect to the database, the code is omitted // create the database logging object logger = new databaselogger (); // initialize the database logging recorder, return logger;} else if (ARGs. equalsignorecase ("file") {// create a log file // create a file logger object logger = new filelogger (); // initialize a file logger, code omitting return logger;} else {return NULL ;}}}
To highlight the design focus, we simplified the above Code and omitted the initialization code of the specific logging class. The static factory method createlogger () is provided in the loggerfactory class to create different types of Logger Based on the input parameters. By using the simple factory mode, we separate the creation and use of the logger object. The client only needs to use the logger object created by the factory class and does not need to care about the object creation process, however, we found that although the simple factory mode achieves object creation and use separation, there are still two problems:
(1) The factory class is too large and contains a large number of if... Else... Code, making maintenance and testing more difficult;
(2) The system expansion is not flexible. If a new type of logger is added, the business logic of the static factory method must be modified, in violation of the "open and closed principle ".
How can we solve these two problems and provide an improvement solution for a simple factory model? This is one of the motivations of the factory method model described in this article.
【Author】 Liu WeiHttp://blog.csdn.net/lovelion]