Comparison between simple factory, factory method and abstract factory Model

Simple factory mode (not one of the GoF23 design modes), factory method mode, and abstract factory mode all belong to the creation design mode. They have their own advantages and disadvantages and are also related to each other, next let's take a look at the comparison between the three: Advantages of mode name definition disadvantages of applicability simple factory by a factory class according to input parameters, dynamically determines which product class to create (these product classes inherit from a parent class or interface. The factory class contains the necessary logical judgment and dynamically instantiates related classes based on the client selection conditions. For the client, dependencies with specific products are removed. Every time you add a function, you must modify the logic judgment of the factory class. The factory class is responsible for creating fewer objects. The customer only knows the parameters of the factory class passed in, and does not care about how to create the object (logic. The factory method defines an interface for creating objects, so that the subclass determines which class to instantiate. The factory method delays the instantiation of a class to its subclass. Due to the use of polymorphism, the factory method overcomes the disadvantages of a simple factory that violates the open-closed principle, and maintains the advantages of the encapsulated object creation process. Each time you add a product, you need to add a product factory class to increase the additional development workload. When a class does not know the class of the object it must create or a class wants the subclass to specify the object it creates, when the class delegates the responsibility of creating an object to one of the multiple help sub-classes and you want to localize the information of which help sub-classes are proxies, you can use the factory method. The abstract factory provides an interface for creating a series of related or mutually dependent objects without specifying their specific classes. 1. Easy to switch product series. Because a specific factory class only needs to appear once during initialization in an application, it is very easy to change the specific factory of an application, it only needs to change the specific factory to use different product configurations. 2. It separates the process of creating an instance from the client. The client uses their abstract interfaces to manipulate the instance. The specific Class Name of the product is also separated by the implementation of the specific factory, does not appear in customer code. If the requirement comes from adding a function, you need to add several classes and modify the related factory classes. 1. A system must be independent of the creation, combination, and representation of its products. 2. A system must be configured by one of multiple product generations. 3. When you want to emphasize the design of a series of related product objects for joint purposes. 4. When you provide a product library, you only want to display their interfaces instead of implementations. Simple factory mode UML diagram factory method mode UML diagram 3. Abstract Factory mode UML diagram the evolution of the above UML diagram shows that the final Abstract Factory is very bloated. One solution is to combine AbstractFactory, ConcreteFactory1, and ConcreteFactory2 into a DataFactory. The three modes share a common drawback: Branch judgment cannot be avoided. To solve this problem, reflection is introduced (to avoid code modification, a configuration file is introduced for data access. The following describes the code for the Abstract Factory method mode (for example, refer to Chapter 15th of the general design mode): The Core code for the solution is: [csharp] using System; using System. collections. generic; using System. linq; using System. text; using System. reflection; // introduce Reflection, which must be written to using System. configuration; namespace Abstract Factory Mode 2 use a simple factory to improve the abstract factory {class DataAccess {# region does not use reflection // private static readonly string db = "Sqlserver"; // Database Name, can be replaced with Access // private static readonly string db = "Access"; // public static IUser CreateUser () // {// IUser result = null; // switch (db) // as the db is set in advance, you can create the corresponding object based on the selected instance // {// case "Sqlserver ": // result = new SqlserverUser (); // break; // case "Access": // result = new AccessUser (); // break; ///} // return result; //} // public static IDepartment CreateDepartment () // {// IDepartment result = null; // switch (db) // {// case "Sqlserver": // result = new SqlserverDepartment (); // break; // case "Access": // result = new AccessDepartment (); // break; //} // return result; //} # endregion private static readonly string AssemblyName = "Abstract Factory Mode 2 use a simple factory to improve the Abstract Factory "; // AssemblyName is the name of the solution. // only reflection is used. // private static readonly string db = "Sqlserver"; // private static readlonly string db = "Access "; // The database name can be changed to Access // use the reflection + configuration file (you need to add the system from the reference before use. configuration) private static readonly string db = ConfigurationManager. deleetask[ "DB"]; // indicates reading the configuration file public static IUser CreateUser () {string className = AssemblyName + ". "+ db +" User "; return (IUser) Assembly. load (AssemblyName ). createInstance (className);} public static IDepartment CreateDepartment () {string className = AssemblyName + ". "+ db +" Department "; return (IDepartment) Assembly. load (AssemblyName ). createInstance (className) ;}}then the code of each related class: [csharp] class User {private int _ id; public int ID {get {return _ id ;} set {_ id = value ;}} private string _ name; public string Name {get {return _ name ;}set {_ name = value ;}}} class Department {private int _ id; public int ID {get {return _ id;} set {_ id = value;} private string _ deptName; public string DeptName {get {return _ deptName;} set {_ deptName = value ;}} interface IUser {void Insert (User user); User GetUser (int id );} class SqlserverUser: IUser {public void Insert (User user User) {Console. writeLine ("adding a record to the User table in Sqlserver");} public User GetUser (int id) {Console. writeLine ("A User table record is obtained by ID in Sqlserver"); return null ;}} class AccessUser: IUser {public void Insert (User user) {Console. writeLine ("adding a record to the User table in Access");} public User GetUser (int id) {Console. writeLine ("Get a User table record by ID in Access"); return null ;}} interface IDepartment {void Insert (Department department Department); Department GetDepartment (int id );} class SqlserverDepartment: IDepartment {public void Insert (Department department Department) {Console. writeLine ("adding a record to the Department table in Sqlserver");} public Department GetDepartment (int id) {Console. writeLine ("getting a Department table record by ID in Sqlserver"); return null ;}} class AccessDepartment: IDepartment {public void Insert (Department department Department) {Console. writeLine ("adding a record to the Department table in Access");} public Department GetDepartment (int id) {Console. writeLine ("obtain a Department table record by ID in Access"); return null ;}} client code: [csharp] User user User = new User (); department dept = new Department (); IUser iu = DataAccess. createUser (); // directly obtain the actual database access instance, without any dependency on iu. insert (user); iu. getUser (1); IDepartment id = DataAccess. createDepartment (); // directly obtain the actual database access instance without any dependent id. insert (dept); id. getDepartment (1); Console. read (); execution result: