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

 I have been learning the design pattern for some time, but this is the first time I applied the design pattern to actual development. Maybe the design content in this article is too simple, but it is an attempt after all. I only want to communicate with you on the homepage. If you have any questions, please kindly advise... Thank you ~

Reason
We have been developing a system for controlling product warehouse receiving and shipment. The basic business process is as follows: First, open a product warehouse receiving contact ticket, and then the warehouse will store the product in kind according to this document, after the number of items to be confirmed is correct, the information should be transferred to the ERP system for accounting control... (For more details, refer)
For this requirement, I simply implemented it in a procedural manner:
Encapsulate a job class to control the warehouse receiving and turning actions:

Code
Public   Class Cellgoodsrec
{
Private   String Bill_no;

Public string bill_no
{< br> Get { return bill_no ;}
set {bill_no = value ;}
}< br>

Public StringExecutereceive ()
{
//Import operations here
}

}

client: Code

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

--> private void btngoodsrec ()
{< br> cellgoodsrec = New cellgoodsrec ();
rec. executereceive ();
}

demand changes
as development approaches the end, the user suddenly raised a question: the original practice can only be applied to the import of semi-finished products, the warehousing operations of finished products are slightly different, and the system should be able to cope with these two situations...
in principle, the simplest practice is simply to add a method for storing finished products into the encapsulated class.

Agile thinking
However, in accordance with the agile development philosophy, when we make changes to requirements, we must consider possible new requirements in the future, our design at this time should be able to easily cope with future demand changes... (do not know whether the understanding is correct ). That is to say, if the user proposes that the system should adapt to the import of semi-finished products and finished products, will there be any possibility of import of raw materials into the system in the future? What should we do at that time? Can I add another method?
According to the OO design principle, a class can only have one reason for its changes (single responsibility principle), and the above measures to cope with changes undoubtedly violate this principle. (for finished products, semi-finished products, and raw materials, any way of warehouse receiving changes must be re-compiled ).
This is the time to enter the design mode. The [encapsulation change point] is just right here. Note that, in either case, all operations are in the warehouse receiving category, but the methods are different. In this case, the warehouse receiving action may be abstracted and encapsulated. In each case, this abstraction completes the specific implementation, in this way, functions are evenly distributed and responsibilities are single. On the client side, we can instantiate different implementations based on the actual situation.

 Use the simple factory model for the first refactoring
Abstract class:

Code
Public   Abstract   Class Goodsreceive
{
Private   String Workorder;

Public string workorder
{< br> Get { return workorder ;}
set {workorder = value ;}
}

Private StringBill_no;

Public   String Bill_no
{
Get { Return Bill_no ;}
Set {Bill_no = Value ;}
}

Public   Abstract   String Executereceive ();

}

Specific types of semi-finished products: Code
Public   Class Cellgoodsrec: goodsreceive
{
Public   Override   String Executereceive ()
{
String Returninfor = Bill_no;

// perform the import of semi-finished products here:

return returninfor;
}< BR >}

finished product class: Code

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

--> class modgoodsrec: goodsreceive
{

Public override string executereceive ()
{< br> /// code here
string transno = workorder;

////Perform the finished product warehouse receiving operation here: Based on the ticket number

ReturnTransno;
}
}

Simple Factory: Code
Public   Class Dbfactory
{

Public   Static Goodsreceive getrectype (receivetype rectype)
{
Goodsreceive goodsrec =   Null ;;

Switch (Rectype)
{
Case Receivetype. Cell:
Goodsrec =   New Cellgoodsrec ();
Break ;
Case Receivetype. Mod:
Goodsrec =   New Modgoodsrec ();
Break ;
}
Return Goodsrec;
}
}

For job convenience, enumeration, receivetype Code

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

--> Public Enum receivetype
{< br> cell, // semi-finished products
mod // finished product
}

Client:

Code
// Semi-finished jobs
Private   Void Btncellrec_click ( Object Sender, eventargs E)
{
Goodsreceive execrfc = Dbfactory. getrectype (receivetype. Cell );

Execrfc. bill_no= "Bn101";//Transfer warehouse receiving ticket number

StringTranferno=Execrfc. executereceive ();

MessageBox. Show (tranferno );
}

// Finished Job
private void btnmodrec_click ( Object sender, eventargs e)
{< br> goodsreceive execrfc = dbfactory. getrectype (receivetype. moD);

Execrfc. workorder= "Wo001";//Transfer ticket number

StringTranferno=Execrfc. executereceive ();

MessageBox. Show (tranferno );
}

To be continued...