Basic design principles of 0-sequence and object-oriented

Recently in the "Head First design mode" is really a good book, in layman's terms, with specific scenes to the common design patterns are very thorough. Slightly sadly, the examples in this book are written in Java and written for us. NET seems to be a little bit uncomfortable. So I wrote the example of each pattern in the book in C #, and, by the way, made some records of the ideas and application scenarios of each pattern, and I was a note to myself, and I hope we can help.

Before entering specific design patterns, let us revisit the object-oriented five basic design principles, it is really worth repeating the aftertaste.

Single Duty principle SRP (Responsibility Principle)
Refers to the function of a class to be single, not all-encompassing. Like a person, the distribution of work can not be too much, otherwise busy all the way, but the efficiency is not high up.

Open closure principle OCP (Open-close Principle)
A module should be open in terms of extensibility and should be closed in terms of change. For example: A network module, the original only server function, and now to join the client function, then you should not modify the server function code under the premise, you can add the client function of the implementation code, which requires at the beginning of the design, the server should be separated from the client, the public part of the abstraction.

Replacement principle (the Liskov Substitution Principle LSP)
Subclasses should be able to replace the parent class and appear anywhere the parent class can appear. For example: The company engaged in annual party, all employees can participate in the lottery, then whether it is the old staff or new employees, whether it is the headquarters staff or the outside staff, should be able to participate in the lottery, or the company will not be harmonious.

The dependency principle (the Dependency inversion Principle DIP) relies specifically on abstraction, which relies on the lower layer. Suppose B is a lower module, but B needs to use the function of a,
At this point, B should not directly use the specific class in a: instead of defining an abstract interface by B, and a to implement the abstract interface, B uses only this abstract interface: thus achieving the purpose of dependency inversion, B also removes the dependency on a, which in turn is an abstract interface dependent on the B definition. It is difficult to avoid relying on the lower module through the upper module, if B is also directly dependent on the implementation of a, then it may cause cyclic dependence. A common problem is that when compiling a module, you need to include the CPP file directly into the B module, while compiling B will also include the CPP file of a directly.

Interface separation principle (the Interface segregation Principle ISP)
The modules are separated by an abstract interface, rather than by a specific class-strong coupling.

Basic design principles of 0-sequence and object-oriented