C # Design Pattern summary

First, Introduction

After this period of time on the design pattern of learning, their feelings are still a lot of, because I now write code, often think of here can use what design mode to reconstruct. So, after you finish the design pattern, you feel it will slowly affect the way you think about writing code. Here is a summary of the design pattern, one can be a comb for all design patterns, and can do an index to help you collect.

PS: In fact, I have seen all the design patterns very early, but did not write a blog, but soon forgotten, and did not play any role, this time to summarize the form of the blog, found that the effect is still very obvious, because through this summary of the way, I understand it more deeply, but also remember the more secure, Also affect their own normal realization of the function of thinking. So, I encourage you to take notes to sort out what you've learned so that you can understand deeper and better, and I'll write about it, and then I'm going to write a series of articles about WCF.

In fact, WCF content is very early also read, and blog Park also has a lot of predecessors write very good, but, I think I still need to summarize, because only this, knowledge is their own, others write how good, you look after, actually still others, so encourage you a few points (for these points, but also a reminder of their own):

1. To do the actual combat in other people's blog examples;
2. After the implementation of the summary, you can write a blog can also record their own cloud notes, etc.;
3. Think about whether you can expand and extrapolate.

Ii. Principles of Design

The fundamental reason to use design patterns is to adapt to changes, improve code reuse, and make software more maintainable and extensible. And, in the design, we also need to follow the following principles: the single Responsibility principle, the open closure principle, the Richter substitution principle, the dependency inversion principle, the interface isolation principle, the synthetic reuse principle and the Dimitri law. Each of the design principles is described below.

2.1 Single Duty principle

As far as a class is concerned, there should be only one cause for it to change. If a class takes on too much responsibility, it is tantamount to coupling these responsibilities, a change in one's responsibilities may affect other responsibilities, and the coupling of multiple responsibilities can also affect reusability.

2.2 Opening and closing principle (open-closed Principle)

The open and closed principle is the OCP (open-closed principle abbreviation) principle, which emphasizes that a software entity (referring to classes, functions, modules, etc.) should be opened to the extension and shut down for modification. That is, each time a change occurs, the behavior of the existing type is enhanced by adding new code instead of modifying the original code.

The best way to conform to the open and close principle is to provide an intrinsic interface and then have all potentially changing classes implement the interface, allowing the fixed interface to interact with the related object.

2.3 Richter Substitution principle (Liskov Substitution Principle)

Liskov Substitution PRINCIPLE,LSP (Richter substitution principle) refers to subclasses that must replace their parent type. In other words, the program behaves the same when the child class replaces the parent class during software development. The parent class can be truly reused only when the subclass has replaced the parent class, and the child class may add new behavior based on the parent class, when the functionality of the software is not affected. To take a look at an example that violates the LSP principle, the exact code is as follows:

public class Rectangle    {public        virtual long Width {get; set;}        Public virtual long Height {get; set;}    }    Square public    class Square:rectangle    {public        override long Height        {            get            {                return base. Height;            }            Set            {                base. Height = value;                Base. Width = value;            }        }        public override long Width        {            get            {                return base. Width;            }            Set            {                base. Width = value;                Base. Height = value;}}    } Class Test    {public        void Resize (Rectangle r)        {while            (r.height >= r.width)            {                r.width + = 1;            }        }        var r = new Square () {Width = ten, Height = ten};         New Test (). Resize (R);     }

The above design, as noted above, when executing the Smarttest resize method, if a rectangle object is passed in, when the height is greater than the width, the width is automatically increased until the height is exceeded. However, if a square object is passed in, it will fall into a dead loop. At this point the root cause is that the rectangle cannot be the parent of the square, and since there is a problem, you can refactor it so that both of them inherit from the Quadrilateral class. The refactored code looks like this:

Quadrilateral public    abstract class quadrangle    {public        virtual long Width {get; set;}        Public virtual long Height {get; set;}    }    Rectangle public    Class Rectangle:quadrangle    {public        override long Height {get; set;}        public override long Width {get; set;}           }    Square public    class Square:quadrangle    {public        long _side;        Public Square (long side)        {            _side = side;        }    } class Test    {public        void Resize (quadrangle R )        {            while (r.height >= r.width)            {                r.width + = 1;            }        }        static void Main (string[] args)        {            var s = new Square (ten);            New Test (). Resize (s);        }    }

2.4 Dependency Inversion principle

Dependency inversion (dependence inversion Principle, DIP) principle refers to the abstraction should not be dependent on the details, the details should be dependent on the abstraction, that is, the proposed "interface-oriented programming, rather than implementation-oriented programming." This can reduce the coupling between the customer and the specific implementation.

2.5 Interface Isolation Principle

The interface isolation principle (Interface segregation Principle, ISP) is that it is better to use multiple specialized interfaces than to use a single total interface. In other words, do not allow a single interface to assume too much responsibility, but should separate each responsibility into a number of specialized interfaces, interface separation. An overly bloated interface is a kind of pollution to the interface.

2.6 Synthetic multiplexing Principles

The principle of synthetic multiplexing (Composite reuse Principle, CRP) is to use some existing objects within a new object to make them part of the new object. The new objects are reused for the purpose of the used functionality by delegating to these objects. Simply put, try to use composition/aggregation and try not to use inheritance.

In order to use the principle of synthetic reuse, the relationship between "has-a" and "is-a" should be distinguished first.

"Is-a" refers to a class that is "one" of another class, a relationship that belongs to it, and "has-a" is different, which indicates that a role has a certain responsibility. A common cause of incorrect use of inheritance instead of aggregation is to mistakenly treat "has-a" as "is-a". For example:

In fact, employees, experiences, students describe a role, such as a person is "manager" must be "employee". In the above design, a person can not have multiple roles at the same time, is "employees" can no longer be "student", this is obviously unreasonable, because now many in-service graduate student, even if the employee is also students.

The above design error stems from the "character" hierarchy and "human" hierarchy structure confused, mistakenly "has-a" as "is-a". The specific solution is to abstract a role class:

2.7 Dimitri Law

The Dimitri rule (law of Demeter,lod) is also called the least knowledge principle (Least knowledge principle,lkp), which means that an object should have as little knowledge of other objects as possible. That is, a module or object should be as small as possible interaction with other entities, so that the system function module is relatively independent, so that when a module is modified, the less affected modules will be expanded more easily.

Some other statements about the Dimitri rule are: communicate only with your direct friends; don't talk to strangers.

The Dimitri rule is used in the appearance pattern (facade pattern) and the mediator pattern (mediator pattern).

C # Design Pattern summary