An attempt to reconstruct the existing system using the design model (2)

On the Practice of this attempt after the last article (http://www.cnblogs.com/Ivan-Yan/archive/2008/10/29/1322119.html), got a few friends (wood wild fox (Neil Chen), T2, etc.) guidance, thank you again for your enthusiastic help.

 Thoughts
After restructuring the warehouse receiving of different products in a simple factory model last time, as friends said, this design is indeed not flexible: if there is a new product (such as raw materials) warehouse receiving operation, there are too many changes: factory class, specific class... in fact, it violates the object-oriented design principle: open and closed.
After studying and thinking, I realized that the design here actually violates the principle of dependency inversion: relying on abstraction rather than concrete implementation. This disadvantage exists in the simple factory model.
To solve this problem, I reconstructed the design again: Factory method model.

Rebuild with factory method mode


Create abstract interfaces for the factory of each product job

Code
 InterfaceIrecfactory
{
Igoodreceive recfac ();
}

Semi-finished factory type:

Code
 ClassCellfactory: irecfactory
{
Igoodreceive irecfactory. recfac ()
{
Return NewCellreceive ();
}
}

Finished factory type:

Code
ClassModfactory: irecfactory
{
Igoodreceive irecfactory. recfac ()
{
Return NewModreceive ();
}
}

Abstract The warehouse receiving job:

Code
InterfaceIgoodreceive
{
StringExecreceive ();
}

Specific types of semi-finished product warehouse receiving jobs:

Code

code highlighting produced by actipro codehighlighter (freeware)
http://www.CodeHighlighter.com/

--> class cellreceive: igoodreceive
{< br> string igoodreceive. execreceive ()
{< br> return " here, run the [import of semi-finished products] job " ;< BR >}

Finished product warehouse receiving operations:

Code

code highlighting produced by actipro codehighlighter (freeware)
http://www.CodeHighlighter.com/

--> class modreceive: igoodreceive
{< br> string igoodreceive. execreceive ()
{< br> return " here, run the [finished product warehouse receiving] job " ;< BR >}

Client-side jobs:

Code
  Private   Void Btncellrec_click ( Object Sender, eventargs E)
{
// Import of semi-finished products
Irecfactory fac =   New Cellfactory ();
Igoodreceive rec = FAC. recfac ();
String Returninfo = Rec. execreceive ();
MessageBox. Show (returninfo );
}

Private   Void Btnmodrec_click ( Object Sender, eventargs E)
{
// Finished product warehouse receiving operation
Irecfactory fac =   New Modfactory ();
Igoodreceive rec = FAC. recfac ();
String Returninfo = Rec. execreceive ();
MessageBox. Show (returninfo );
}

It can be seen that the client-side jobs all rely on abstraction, which makes the system more stable in the face of demand changes.
If the user needs to store raw materials into the database at this time, the design at this time can be easily handled.
Respond to demand changes

Add raw material warehouse receiving operation class:

Code

code highlighting produced by actipro codehighlighter (freeware)
http://www.CodeHighlighter.com/

--> class rawreceive: igoodreceive
{< br> string igoodreceive. execreceive ()
{< br> return " here, perform the [import of raw materials] job " ;< BR >}

Create a factory for raw material operations:

Code
ClassRawfactory: irecfactory
{
Igoodreceive irecfactory. recfac ()
{
Return NewRawreceive ();
}
}

As you can see, in the face of changes, the system can be easily expanded without any changes to the implementation of the original product. This is the key to the object-oriented design principle.

The suggestions of a few friends can actually be reflected on the client:

Code
  Private   Void Btncellrec_click ( Object Sender, eventargs E)
{
// Import of semi-finished products
// Irecfactory FAC = new cellfactory ();

String Factoryname = System. configuration. configurationmanager. configurettings [ " Cellfactory " ]. Tostring ();
Irecfactory fac = (Irecfactory) Assembly. Load ( " Factorymethoddemo " ). Createinstance ( " Factorymethoddemo. " + Factoryname );
Igoodreceive rec = FAC. recfac ();
String Returninfo = Rec. execreceive ();
MessageBox. Show (returninfo );
}

Private   Void Btnmodrec_click ( Object Sender, eventargs E)
{
// Finished product warehouse receiving operation
// Irecfactory FAC = new modfactory ();

String Factoryname = System. configuration. configurationmanager. configurettings [ " Modfactory " ]. Tostring ();
Irecfactory fac = (Irecfactory) Assembly. Load ( " Factorymethoddemo " ). Createinstance ( " Factorymethoddemo. "   + Factoryname );
Igoodreceive rec = FAC. recfac ();
String Returninfo = Rec. execreceive ();
MessageBox. Show (returninfo );
}

App. config Code
<? XML version = "1.0" encoding = "UTF-8" ?>
< Configuration >
< Appsettings >
< Add Key = "Cellfactory" Value = "Cellfactory" />
< Add Key = "Modfactory" Value = "Modfactory" />
</ Appsettings >
</ Configuration >

If I want to use reflection to complete the operation, the client's specific factory operations will also be configured in the config document, which will be more flexible in future maintenance. For example, if the name of a factory changes, you only need to modify the config document, and the client does not need to change it.