Design Mode-factory method mode

Factory method mode:

Defines an interface for object creation, but this class does not actually generate an object instance, but is instantiated by its subclass. The factory method mode delays class Instantiation to the subclass.

Structure:

Solved problems:

In the software system, we will encounter such a problem. After a certain operation is implemented through a channel, due to demand changes or other reasons, this operation needs to be implemented through another channel, so we have to modify this implementation method. how to encapsulate such a variable. the factory method mode cannot solve the problem of modification, because of the changes in requirements, we mayCodeThe purpose of encapsulation is to reduce the number of changes, that is, the original modification is 10 places, and now you can modify one place.

The premise of using this mode is that all objects can abstract common methods within the scope of using this class.

For example:

Shows the transportation of oil in life. we decided to use train transportation, so we established a class to implement the method of transporting oil by train. this method is also used in many cities. one day, the demand changed. transportation of oil by train caused serious pollution in the city and the safety was not high. Pipeline Transportation was required. so we need to modify the initial class and create a method: oil pipeline (). in addition, a large number of references are modified to the location where train fuel is used.

The first class:

   Public ClassCarryoil {Public StringCarrybytrain (){Return "Use train";}}
 

 
After modification:
 

   Public     Class  Carryoil {  Public     String  Carrybytrain (){  Return     "  Use train  "  ;}  Public    String  Carrybypiping (){  Return     "  Use Piping  "  ;}} 

In this way, what should we do if we require air transportation or vehicle transportation next time? ContinueCarryoilAdd new methods to adapt to changes in new requirements. This violates the "open and closed principle" (open to extensions and closed to modifications). We will observe these methods carefully, whether using trains, cars, airplanes, or pipelines to transport oil, you can abstract a method: transportation of oil. Therefore, our design is as follows:

 

At this point, if we add a new transportation method, we only need to inherit the carryoil class and implement the carry method. at this time, we do not need to worry about how the other two transport modes are implemented. in line with the single Responsibility Principle in the object-oriented design, but also well applied the "open and closed principle ". the code for client calling is as follows:

     Protected     Void  Page_load (  Object  Sender, eventargs e) {carryoil C  =     New  Carryoilwithtrain (); display (c );} Void  Display (carryoil c) {response. Write (  "  Method:  "     +  C. Carry ()  +     "  <HR/>  "  );} 

It seems that there is no problem with the design. If the pipeline is used for transportation, you can simply change it to carryoilwithpiping. but what if the above Code is called multiple times on the page and all of them need to be changed to carryoilwithpiping?

For example:

 
Protected VoidPage_load (ObjectSender, eventargs e) {carryoil C1 =NewCarryoilwithtrain (); display (C1); carryoil C2 =NewCarryoilwithtrain (); display (C2); carryoil C3 =NewCarryoilwithtrain (); display (C3 );}VoidDisplay (carryoil c) {response. Write ("Method:"+ C. Carry () +"<HR/>");}
 

 

In this case, if you want to use a pipeline for transportation, the three carryoilwithtrain will be modified. So the factory method mode appears:

Code:

Public InterfaceItransport {carryoil gettraffic ();}Public ClassTransportwithtrain: itransport {PublicCarryoil gettraffic (){Return NewCarryoilwithtrain ();}}Public ClassTransportwithpiping: itransport {PublicCarryoil gettraffic (){Return NewCarryoilwithpiping ();}}
 

 
In this case, the page is called as follows:
 

Protected VoidPage_load (ObjectSender, eventargs e) {itransport factory =NewTransportwithtrain (); carryoil C1 = factory. gettraffic (); display (C1); carryoil C2 = factory. gettraffic (); display (C2); carryoil C3 = factory. gettraffic (); display (C3 );}VoidDisplay (carryoil c) {response. Write ("Method:"+ C. Carry () +"<HR/>");}
 

 
In this case, you only need to modify transportwithtrain to transportwithpiping to make one modification, instead of modifying it as shown in the preceding three steps.
 

 
In addition, no specific class is used during page calling (the specific product class here ). the transportwithtrain class is called in multiple pages. What should I do if multiple pages call this class?
 

Now you can set itransport factory =NewTransportwithtrain (); put it in a class, as follows:
 

 
Public ClassCreatefactory {PublicCreatefactory (){//// Todo: add the constructor logic here//}PublicItransport createtransportfactory () {itransport TRAN =NewTransportwithtrain ();ReturnTran ;}}
 

 
Page call time:
 

Protected VoidPage_load (ObjectSender, eventargs e) {createfactory cf =NewCreatefactory (); itransport factory = Cf. createtransportfactory (); carryoil c = factory. gettraffic (); display (c );}VoidDisplay (carryoil c) {response. Write ("Method:"+ C. Carry () +"<HR/>");}
 

 

You can call such a statement on multiple pages. If you need to modify it, you only need to replace transportwithtrain in createtransportfactory in the createfactory class with transportwithpiping.