Simple Factory design pattern (Factory)

The introduction recently saw a video explaining the. NET design pattern in Youtub, where one of the authors ' understandings impressed me deeply: the so-called design pattern is actually using object-oriented programming to solve the problem of tight coupling and low expansion in peacetime code. Another point of view is that the design pattern is differentiated, the structure pattern (Architecture pattern), and the schema type (Architecture Style). As shown

Design pattern: is based on the code level, is to solve the problem between the functional modules to adopt appropriate design patterns, such as dependency injection, simple factory, adapter mode and so on, but these have a function point is that we often say that patterns are often based on the code level, I've never heard of my entire application using a pattern (it sounds weird).

Architecture Pattern: is based on functional and conceptual aspects. For architectural patterns, we should look at functional modules and structure relationships between hierarchies to consider the appropriate approach.

Architecture Style: It is also a higher level conceptual dimension based on the schema pattern (Architecture pattern), focusing on the relationship between the client and the server to consider the design.

"Simple Factory mode"

The Simple Factory mode is a design pattern commonly used in development, and it mainly uses to solve the problem that the correlation but the non-homogeneous initialization is tightly coupled . So, probably most people don't quite understand that. Here is a simple explanation for borrowing a demo code from the video mentioned above.

The following are examples of tight coupling on a common class design: We implement white-collar, worker, business owners three entity classes, at the client (winform/wpf/console) We need to access these three class instances to invoke the respective tax method, because different occupations pay taxes and ratios differently, So the implementation of the tax is actually different.

Issue 1: Violation of open close Principle (opening closure principle). If we need to add a new civil servant entity class, we need to modify the client, first to add a reference to the Civil service entity class, and then to extend the if Else statement block. If you are a large application, you need to change all the original entity class references, and the same if else statement, that would be a very bad thing. In fact, this is a typical example of a tight coupling of client-initiated entity classes, where the client contains references to different entity classes and initializes different entity classes based on the conditions.

Question 2: White-collar workers, business owners and even civil servants although different class patterns are relevant, the most typical polymorphic implementations should be applied to the common behavior of tax.

How to solve the appeal problem? ---simple Factory mode

We can adjust the design of the class as follows

1. The use of inheritance and virtual methods to separate white-collar workers and business owners of the entity class between the common and different, the approximate code is as follows:

 Public class Citizen    {        publicstringgetset;}          Public Virtual Double Paytax ()        {            return;        }    }

Each different entity class, such as a white-collar class, can rewrite the logic of Paytax itself, and then for a new class, such as a civil servant class, only need to add a new class implementation, without having to change the client's existing code-the open closure principle

2. The code for the factory class is roughly the following: for if you need to extend a new entity class, such as a civil servant class, add a new class only to initialize the entity class method in the factory class. This does not need to modify the existing logic for the new extension function, but the new implementation of this is in line with the open closure principle, followed by the removal of the client's original business logic if ELSE judgment, the client and the business layer only rely on a base class (abstract), rather than rely on the specific implementation (white-collar, workers, Business owner entity Class), which also enables decoupling between the client and the service layer.

 //Design pattern:simple Factory Pattern     Public Static classCitizenfactory {Private Staticdictionary<string, citizen> _citizen =Newdictionary<string, citizen>();  Public StaticCitizen CreateInstance (stringtypestr) {            if(_citizen. Count = =0) {_citizen. ADD ("White Collar",NewWhite Collar ()); _citizen. ADD ("Workers",Newworkers ()); _citizen. ADD ("Business Owners",NewBusiness owners ()); }            return_CITIZEN[TYPESTR]; }    }

This is the problem that the simple factory model solves, and we understand that we can use the simple factory model to solve this kind of problem.

"Summary": The simple Factory mode is mainly to solve the problem that the class constructs and initializes the close coupling and the dependence between the client, and splits the if ELSE branch to judge the difficulty. In general, if there is an association between entity classes in the system, and there are too many branches in the client logic to determine the initialization class object logic, simple Factory mode can be used to decouple. There are also many examples of simple factory models, such as the use of factory patterns in order to implement different database (Sql/mysql/access) interface extensions and to invoke different Web services.

Demo: Here I have a similar case to write two versions of the demo example, one is tightly coupled with the pre-modified code, one is the use of simple Factory mode after the code, interested students can be downloaded to practice.

Project structure:

Red Callout (. SFP) ends with the adjusted code, non-red callout of the pre-modified code.

Soucecode:http://files.cnblogs.com/files/georgeheaven/01.simplefactorypattern.zip

Simple Factory design pattern (Factory)