[Design mode sorting Note 1] basic knowledge

[Guide]

[Design mode sorting Note 1] basic knowledge

[Design mode sorting Note 2] simple factory Mode)

[Design mode sorting Note 3] factory Mode)

[Design pattern sorting Note 4] abstract factory pattern (Abstract Factory)

[Design pattern sorting Note 5] creator pattern (builder)

[Design pattern arrangement Note 6] Summary of factory pattern and creator Pattern

[Design mode sorting Note 7] prototype)

[Design mode sorting Note 8] Singleton)

[Design mode sorting Note 9] appearance mode (facade)

... Later, including some examples

[/Guide]

 

The design pattern has a very wide range. Recently, I have made some research on it. I feel like I have learned something every time, we will find that the knowledge we get will be more comprehensive than what we learned previously, otherwise it will be scattered in our heads. The following example shows a large enterprise's wage calculation model, because there are many subsidiaries in different regions, of course, the wage calculation method is also different.

First define an interface to determine the method for calculating the salary, as shown below:

Using System;

NamespaceConsoleapp
{
Public InterfaceIsalary
{
VoidCommandsalary ();
}
}

 

Different subsidiaries in different regions inherit the commandsalary method of this interface, and the following is the calculation method of Shenzhen and Beijing. Two types of design are as follows:

Code

Using System;

namespace consoleapp
{< br> Public class shenzhensalary: isalary
{< br> Public void commandsalary ()
{< br> console. writeline ( " This is the salary calculation module of Shenzhen subsidiary " )
}< BR >}

 

Beijing subsidiary

Code

Using System;

namespace consoleapp
{< br> Public class beijinsalary: isalary
{< br> Public void commandsalary ()
{< br> console. writeline ( " This is the salary calculation module of Beijing subsidiary " )
}< BR >}

 

The basic classes have been designed, and many people willCodeTo use a new one, such code may be difficult to maintain, give people a bad feeling. Or call it like the following Code. The Code is as follows:

Code

Using System;

Namespace Consoleapp
{
Class Program
{
Public   Static   Void Main ( String [] ARGs)
{
Isalary salary = Createsalary ( " Beijin " ); // When you need to call the salary calculation process of a subsidiary, transfer the name of the subsidiary
Salary. commandsalary ();
Console. Readline ();
}

///   <Summary>
/// Returns the corresponding instance by the company name passed in.
///   </Summary>
///   <Param name = "companyName"> Subsidiary name </Param>
///   <Returns> </returns>
Private   Static Isalary createsalary ( String CompanyName)
{
Isalary salary =   Null ;
If (CompanyName =   " Shenzhen " ) // Here, we can use more methods to determine whether to return the corresponding instance with different names.
{
Salary =   New Shenzhensalary ();
}
Else   If (CompanyName =   " Beijin " )
{
Salary =   New Beijinsalary ();
}
Return Salary;
}
}
}

 

In this way, we can call the calculation to get the salaries of various subsidiaries. for small companies, this design is already quite perfect, but for a large company, there may be dozens or even hundreds of subsidiaries, so that more if statements are needed in createsalary, which is obviously very bad for maintenance, so how should we design it? This is the design model to be discussed,NextArticleThis module is written in a common factory mode.

Note: This is a common writing method for new users. This is not about the factory model. Here we only say that the writing class is not good and does not conform to the system design mode. Let's take a counterexample first, the design mode will be introduced later. Some friends did not see it clearly. Mark it.

 

(Note: This is my learning experience and may cause major mistakes. please correct me)