Design Patterns (0): Introduction and solid Principles

In software engineering, design pattern is a kind of solution that is widely existed (recurring) in software design.
Design patterns are not directly used to write code, but rather describe a solution to the problem in a variety of situations. Object-oriented design patterns typically describe relationships and interactions in a class or object, but do not involve specific classes or objects that are used to complete an application. Design patterns can make instability dependent on relative stability, rely on relative abstraction, avoid tight coupling that can cause trouble, and enhance the ability of software design to face and adapt to change.
Not all software models are design patterns, and design patterns refer specifically to problems at the "design" level of software. There are other modes of non-design mode, such as schema mode. At the same time, the algorithm is not a design pattern, because the algorithm is mainly used to solve the computational problems, rather than design problems.
GOF "design pattern" involves 23 models, divides the design pattern into the creation pattern, the structure pattern, the behavior pattern, respectively from the object creation, the object and the object structure combination as well as the object interaction these three aspects for the object-oriented system modeling method to give the analysis and the instruction.
　　　　

　　Create Design Patterns (creational Patterns) describes how to create an object. It hides the details of the object creation so that the program code does not depend on the specific object, so that when we add a new object, there is little need to modify the code.
　　Structural Design Patterns (Structural Patterns) describes how classes and objects are organized together to form large structures, primarily using inheritance to organize interfaces or implementations.
　　Behavioral Design Patterns (behavioral Patterns) describes the algorithm and task assignments between objects, which describe not only the design patterns of objects or classes, but also the communication patterns between them.

Solid principle:
SOLID (single function, open/close principle, Richter replacement, interface isolation, and dependency reversal) is by Robert? C. Martin's acronym for memorization, introduced in the early 21st century [1], refers to the five basic principles of object-oriented programming and object-oriented design. When these principles are applied together, they make it more possible for a programmer to develop a system that is easy for software maintenance and expansion.
　　 single function Principle(Single responsibility principle) specifies that each class should have one function, and that the function should be fully encapsulated by this class. Simply put, just keep it simple, don't think so much, do one thing well. Conversely, if a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in responsibility may weaken or inhibit the ability of the class to perform other duties, and the design will suffer unexpected damage when the change occurs.
　　 Opening and closing principleSpecifies that "objects in the software (classes, modules, functions, etc.) should be open to the extension, but are closed for modification". In the face of changes in demand, changes to the program are made by adding new code, rather than changing the existing code. However, when the code was originally written, it was difficult to predict the occurrence of the change, which required the creation of abstractions to isolate the similar changes that occurred later on when the change occurred. Developers should abstract only those parts of the program that exhibit frequent changes, rejecting immature abstractions and abstractions as important as themselves.
　　 The principle of the Richter replacement(Liskov Substitution principle) is a special definition of a subtype. A derived class (subclass) object can be used to replace its base class (superclass) object. Ostriches, for example, cannot inherit from a bird with flying characteristics.
　　 Interface Isolation principle(English: Interface-segregation principles, Abbreviation: ISP) indicates that no client (client) should be forced to rely on the method it does not use. The interface Isolation principle (ISP) splits very large, bloated interfaces into smaller and more specific interfaces so that customers will only need to know the methods they are interested in. This narrowing of the interface is also known as the role interface (roles interfaces). The purpose of the Interface Isolation principle (ISP) is for the system to unlock the coupling, making it easy to refactor, change, and redeploy. In the case of the ostrich above, we should split the bird interface into a flying bird interface and an flightless bird interface, then the ostrich inherits from the flightless bird interface, and if the ostrich inherits directly from the bird interface, it must implement the fly () operation, which violates the interface isolation principle because it relies on methods that it does not apply.
　　 Dependency Reversal Principle(Dependency inversion principle) refers to a specific decoupling (a traditional dependency is established at a high level, and a specific policy setting is applied to a lower-tier module). In this situation, the dependency module is reversed (for example: inversion) in order for the high-level modules to be independent of the implementation details of the lower levels of the module. The principle provides that:
High-level modules should not rely on lower-tier modules, both of which should rely on abstract interfaces.
Abstract interfaces should not be dependent on specific implementations. The specific implementation should rely on an abstract interface.
For example, there are various manufacturers of computers, but for the convenience of use and maintenance, they should use a unified mouse interface, a unified keyboard interface. To be blunt, it is that each manufacturer relies on a unified standard interface to produce their products, and consumers only use a unified interface.

The basis of reusable object-oriented software-design patterns, with its reusable design intent, sophisticated logical thinking by the vast number of object-oriented programming in the pursuit of. But many programmers often turn the question of thinking into what patterns they encounter. This kind of stereotyped writing-type thinking has seriously affected the artistic design of the program, and solidified the idea of the programmer, which violates the original intention of designing pattern. In fact, there is no need to rote the names of these principles, the program is written more, you will certainly notice these things, mastering the essence is the most important.

Reference:
Https://zh.wikipedia.org/wiki/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F_ (%E8%AE%A1%E7%AE%97%E6%9C%BA)
Https://zh.wikipedia.org/wiki/SOLID_ (%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)
Http://www.cnblogs.com/aehyok/archive/2013/05/21/3091917.html

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Design Patterns (0): Introduction and solid Principles