The basic design principle of object-oriented

These days re-read the "Big Talk design mode", found that there are different sentiment, but also on the internet to find the "Agile software Development-principles, patterns and practices," a book, the preface of the book there is a paragraph I think very reasonable: "Beautiful things than ugly to create cheaper and faster." "The design of a software is not about the pursuit of the code of Elegance, but also related to production costs." The technology gurus have been groping for a long time in the study of software architectures, from process-oriented to object-orientated, from design principles to design patterns, and summed up many of the classic principles of design, and we just stand on the shoulders of giants and look far away.

From the "Big Talk design mode", we will certainly find that the classic 23 models behind, in fact, follow some basic principles . And the design principle is realized by the design pattern, this is the relationship between them, so understanding the principle is absolutely instructive for understanding the pattern. Here are some of my study notes in the process of reading, I think there is a certain reason.

The most basic design principles are 5: single Duty principle, open closure principle, dependency inversion principle, interface isolation principle, Richter scale (Liskov) substitution principle.

1 Single duty principle (SRP)

　　for a single responsibility principle, the core idea is: A class, it is best to do only one thing, only a change that caused it . The principle of single responsibility can be regarded as the extension of low coupling, cohesion in object-oriented principle, defining responsibility as the cause of change, in order to improve cohesion to reduce the cause of change. The more responsibilities that may cause it to change, the more it will lead to a dependency on responsibility, which has an impact on each other, thus greatly damaging the cohesion and coupling degree. A single function in the general sense is that there is only one single feature, and do not implement too many functional points for the class to ensure that the entity has only one cause for it to change.

Focus, is a person's excellent quality; the same, single is also a good design of a class. Mixed's unclear responsibilities will make the code look particularly awkward reaching, have a loss of beauty and inevitably lead to an ugly system error risk.

2 Open Closure principle (OCP)

For the open closure principle, it is the core of the object-oriented principle, the goal of software design is to package change, reduce coupling, and the open closure principle is the most direct embodiment of this goal.

The core idea of the open closure principle is that the software entity should be extensible and non-modifiable. That is, open to the extension, closed to the modification.

Therefore, the open and closed principle is mainly embodied in two aspects: 1, open to expansion, meaning that there are new requirements or changes, the existing code can be extended to adapt to the new situation. 2, to modify the closure, means that once the design of the class, you can complete its work independently, and do not make any attempt to modify it.

The core idea of implementing open and closed closure principle is to abstract programming, but not specific programming, because the abstraction is relatively stable. So that the class depends on the fixed abstraction, so the modification is closed, and through the object-oriented inheritance and polymorphism mechanism, it can realize the inheritance of the abstract class, by covering its methods to change the inherent behavior, to realize the new expansion method, so it is open.

"Demand always changes" there is no immutable software, so it is necessary to use closed open principle to close the change to meet demand, but also to maintain the internal software packaging system stability, not affected by the change in demand.

3 Dependency Inversion principle (DIP)

The core idea of the dependency inversion principle is that it relies on abstraction. In particular, high-level modules do not rely on the underlying modules, both of which are dependent on abstraction;

Dependencies are bound to exist between classes and classes, modules, and modules. When there is a tight coupling between the two modules, the best way is to separate the interface and implementation: To define an abstract interface between dependencies so that the high-level module calls the interface, and the underlying module to implement the definition of the interface, so as to effectively control the coupling relationship, to rely on the abstract design goals.

Abstract stability determines the stability of the system, because the abstraction is constant, the dependence on abstraction is the essence of object-oriented design, but also the core of the dependency inversion principle.

Dependence on abstraction is a common principle, and sometimes it is unavoidable to rely on details, and it is necessary to weigh the trade-offs between abstraction and specificity, not the same way. depending on the abstraction, it is programming the interface, not programming the implementation .

4 Interface Isolation principle (ISP)

　　The core idea of the interface isolation principle is to use multiple small, dedicated interfaces instead of a large total interface.

Specifically, the principle of interface isolation is that the interface should be cohesive, and the "fat" interface should be avoided. The dependency of a class on another class should be based on the smallest interface, and do not force reliance on the unused method, which is an interface pollution.

Interfaces effectively isolate detail and abstraction, embodying all the benefits of abstract programming, and interface isolation emphasizes the uniqueness of interfaces. But the fat interface has the obvious disadvantage, causes the realization the type must completely implement the interface all methods, the property and so on, but some time, the implementation type does not need all the interface definition, in the design this is "The waste", and in the implementation this will have the latent problem, the modification of the Fat interface will cause a series of client program to modify , sometimes it's a disaster. In this case, the decomposition of the Fat interface into a number of characteristics of the customization method, so that the client only relies on their actual invocation of the method, thereby relieving the client does not rely on the methods they do not use.

The main methods of separation are the following two kinds: 1, the separation of delegates, by adding a new type to entrust the customer's request, isolate the client and interface direct dependence, but will increase the system overhead. 2, multiple inheritance separation, through the interface multiple inheritance to achieve customer demand, this way is better.

5 Richter (Liskov) Replacement principle (LSP)

　　The core idea of the Liskov substitution principle is that subclasses can be substituted wherever any parent class appears. This idea is embodied in the constraints of inheritance mechanism, only the subclass can replace the base class, it can ensure that the system in the runtime to identify the subclass, which is the basis of ensuring inheritance reuse. In the specific behavior of the parent class and subclass, you must strictly grasp the relationship and characteristics in the inheritance hierarchy, replace the base class with the subclass, and the behavior of the program will not change. At the same time, this constraint, in turn, is not true, and the subclass can replace the base class, but the base class does not necessarily replace the subclass.

The Liskov substitution principle mainly focuses on the establishment of abstraction and polymorphism on the basis of inheritance, so only by following the principle of Liskov substitution can we ensure that inheritance reuse is reliable. The way to do this is to interface-oriented programming: to abstract the public part into a base class interface or abstract class, and to support the same responsibilities in a subclass by extract the method of the parent class through the abstraction class.

The Liskov substitution principle is about the design principle of the inheritance mechanism, violating the principle of Liskov substitution inevitably leads to violating the principle of open closure.

The Liskov substitution principle can ensure that the system has good extensibility and realizes the abstraction mechanism based on polymorphism, which can reduce the code redundancy and avoid the type discriminant of the running period.

The above is the 5 basic design principles, like the golden rule in object-oriented programming, abide by the code can be made more vivid, easy to reuse, easy to expand, flexible and elegant. Different design patterns correspond to different requirements, while design principles represent the eternal soul, which needs to be adhered to in practice. As Arthur J.riel in the revelation of Ood there: "You do not strictly abide by these principles, and you will not be punished by the punishment of religion against them." But you should think of these principles as alarms, and if you violate one of them, the alarm will ring. ”

Keep in mind the names and works of these technical masters, and delve into the moves and experiences that have made object-oriented programming so dazzling, along these paths of wisdom, and I feel that we will not only improve the technology, but also find something outside the design, Because OOP also contains a lot of life wisdom. There are also some principles extracted on the Web:

6 Demite (LoP)
The Dimitri principle is also called the least knowledge Principle: If two classes do not communicate directly, then these two classes should not have a direct interaction. If a class is to invoke another class, it is called through a third party. The Dimitri rule first emphasizes the premise that each class should minimize the access rights of the members in the structure design of the class. The fundamental idea of the Dimitri Law is to emphasize the loose coupling between classes. The weaker the coupling between classes, the more beneficial it is to reuse, and a class that is weakly coupled is modified to not affect the related classes.

7 synthesis/Aggregation multiplexing principles (composite/aggregate reuse principle or Carp)
Also known as the synthetic multiplexing principle, is to use some existing objects within a new object to make them part of the new object, and the new objects are reused for the purpose of the existing functionality by delegating to these objects. I am white is to try to use composition/aggregation, try not to use inheritance.

Original address:
http://ce.sysu.edu.cn/hope2008/Education/ShowArticle.asp?ArticleID=8858
http://yysyb123.blog.163.com/blog/static/19205047201011954850595/