Factory Method Model Introduction:
The meaning of the factory method (Factory) pattern is to define a factory interface that creates product objects, deferring actual creation to subclasses. The Core factory class is no longer responsible for the creation of the product, so the core class becomes an abstract factory role that is responsible only for the interfaces that must be implemented by the specific factory subclass, so the benefit of further abstraction is that the factory method model allows the system to introduce new products without modifying the specific factory role.
Factory method Pattern Structure diagram:
Role Categories:
Abstract Factory Role: is the core of the factory method pattern and is independent of the application. The factory class of any object created in the schema must implement this interface.
Specific factory role: This is a specific factory class that implements the abstract factory interface, contains logic that is closely related to the application, and is called by the application to create a Product object
Abstract product Role: The supertype of objects created by the factory method pattern, which is the common parent class of the Product object or the shared interface. In the above picture, this role is light.
Specific product role: This role implements the interface defined by the abstract product role. A specific product has a specific factory to create, they often one by one correspondence.
Introduction of practical Examples:
In the last blog post simple factory model, the following implementations are implemented using the simple factory pattern: if there is a household management system in which the household type is variable, the rent calculation formulas for each tenant type are different, for example: Type a household rent = days * Unit price + performance *0.005;b type of household rent amount = Month * (monthly price +performance*0.001) Here we achieve the customer's needs, but if the customer needs to add the C-type store and D-type stores, and their algorithm requirements are different, this time we need to do the C,d type store creation, and inherits the Ishop interface, realizes inside the method, simultaneously also must continue to modify the factory class in SWITC to add the case to capture creates the corresponding store object, once appears this kind of situation, is unfavorable to the program Expansibility and the project later maintenance.
1. Analysis: The store has the common behavior characteristic, all must carry on the shop rent computation behavior, we abstract the ishop, inside waits for realizes the computation store rent method behavior.
Using System;
Using System.Collections.Generic;
Using System.Linq;
Using System.Text;
Namespace Factoryentiy
{public
interface ishop
{
double getrent (int days, double dayprice, double performance);
}
2. We implement the Isho interface inside the method to create A,b type stores.
using Factoryentiy; using System; using System.Collections.Generic; using System.Linq
;
Using System.Text; namespace Productenity {///<summary>///Inherits store interface, implements the behavior method inside, namely algorithm///</summary> public class Ashop:isho p {///<summary>//////Type a store rental amount, days * unit price + performance *0.005///</summary>///<param name= "Day" &G t; days </param>///<param name= "Dayprice" > Daily price </param>///<param name= "Performance" > daily average performance &L t;/param>///<returns></returns> public double getrent (int days, double dayprice, double Performan
CE) {Console.WriteLine ("A store's rent algorithm");
Return days * dayprice + performance * 0.01; }
}
}
Using Factoryentiy;
Using System;
Using System.Collections.Generic;
Using System.Linq;
Using System.Text;
Namespace productenity
{
///<summary>
///Inherits store interface, implements the behavior method inside, namely algorithm
///</summary>
public class Bshop:ishop
{
///<summary>
///B-type store rent = month * (monthly price +performance*0.001)
/// </summary>
///<param name= "month" > Months </param>
///<param name= "Monthprice" > Monthly Unit Price </param>
///<param name= "Performance" > Monthly average performance </param>
///<returns></returns > Public
double getrent (int month, double Monthprice, double performance)
{
Console.WriteLine (" b store's rent algorithm ");
Return month * (Monthprice + performance * 0.001);}}
3. Consider, under what circumstances, the creation of a store entity, rent calculations for different stores, and facilitate subsequent additions and modifications. So we created the Ifactroy interface, which is the way to create the store objects that are yet to be implemented.
Using Factoryentiy;
Using System;
Using System.Collections.Generic;
Using System.Linq;
Using System.Text;
Namespace FactoryMethod
{
///<summary>
///factory class, create store type entity
///</summary>
Public Interface Ifactory
{
ishop createshop ();
}
}
4. Now we can inherit from Ifactory, implement inside create corresponding store object.
Using Factoryentiy;
Using FactoryMethod;
Using Productenity;
Using System;
Using System.Collections.Generic;
Using System.Linq;
Using System.Text;
Namespace productenity
{
///<summary>
///inherit factory class, create type a store entity
///</summary>
public class Createbshop:ifactory
{public
ishop createshop ()
{return
new AShop ();
}
}
}
Using Factoryentiy;
Using FactoryMethod;
Using Productenity;
Using System;
Using System.Collections.Generic;
Using System.Linq;
Using System.Text;
Namespace productenity
{
///<summary>
///inherit factory class, create B-type store entity
///</summary>
public class Createashop:ifactory
{public
ishop createshop ()
{return
new Bshop ();
}
}
}
5. After that, based on the current store type, what kind of algorithm should be used for this type of store:
Using Factoryentiy;
Using System;
Using System.Collections.Generic;
Using System.Configuration;
Using System.Linq;
Using System.Reflection;
Using System.Text; Namespace Factorymethod.app {class Program {static void Main (string[] args) {string shopname = Config
urationmanager.appsettings["Createshopclassname"]; Shopname to create the store class name, where =createashop ifactory af = (ifactory) assembly.load ("Productenity").
CreateInstance ("productenity." + shopname);
The first productenity is the name of the DLL, and the second productenity is the namespace of the project. Ishop as = af. Createshop (); Double total = as.getrent (30, 300, 2000);
30 days/100 Yuanri average performance is Console.WriteLine ("The Rent for the type a store is:" + total);
Console.WriteLine ("============="); Ifactory bf = (ifactory) assembly.load ("Productenity").
CreateInstance ("productenity." + "Createbshop");
Createbshop can be saved as a configuration or in a database,//Note that the save string should be the same as the class name created in the project,//Otherwise reflection will not find a class under that item. Ishop Bs = bf. Createshop (); Total = Bs.getrent (30, 300, 2000);
30 days/100 Yuanri average performance is Console.WriteLine ("The Rent for the type a store is:" + total);
}
}
}
Here we use reflection to create the object, replace the previous factory class through the switch to create the object of the way, in favor of the next new type of store additions and algorithmic modifications added and maintenance in the project after the change in demand, we only need to re add c,d type store in the project, Inherit the method inside the Ishop implementation, at the same time, add the inherited Ifactroy interface, create the corresponding store object to compile the ProductEnity.dll of the project, and then compute the store algorithm for that c,d type by reflection. You do not need to modify the original engineering class code.
The entire project is structured as follows:
The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.