java--Seven design principles of object oriented

Before we learn the seven principles of object-oriented design, we should have a good understanding of basic encapsulation, inheritance and polymorphism, as well as the ability to encode abstract classes and interfaces, because design patterns are the integrated application of the above knowledge points.
In addition, before contacting the specific design pattern, the object-oriented seven design principles will let you know the inevitability and significance of the design pattern appearing.

The following are the seven-object design principles

Object-oriented seven design principles:

1. Opening and closing principle
2, the Richter replacement principle
3. Principle of Sole responsibility
4. Interface Isolation principle
5. Dependency Inversion principle
6. Dimitri Principle
7. Combinatorial/Aggregate Reuse principle

1, the precise meaning of each kind of design thought, concretely as follows:
First of all seven design ideas from the overall understanding.
First, the opening and closing principle:
This one is put in the first place to understand that its meaning is open to the extension and closed for modification. The explanation is that the code we have written cannot be modified because of changes in demand. We can address the need for change by adding code.
Of course, this is an ideal state, in reality, we should try to narrow this change.
To explain the significance of this principle, we use the reverse thinking way to think. If every change in demand to modify the original code, that the original code has been modified the risk of error, of course, there are intentional and unintentional changes, will lead to the original function of normal operation of the risk of failure, so it is likely to carry out the terrible butterfly effect, so that maintenance work.
In the final analysis, the open and closed principle in addition to the surface of the scalability is strong, in the enterprise more value is the maintenance costs.
Therefore, the opening and closing principle is the first principle of design pattern, its subtext is: to control the change in demand risk, reduce maintenance costs.
The following principles serve the purpose of this principle.
Second, the Richter replacement option:
The implication of this principle is that subclasses can replace their parent classes anywhere. Explain, this is the premise of polymorphism, many of the so-called flexibility behind us, are not changing the type of declaration, change the instantiation class to complete the requirements change. Of course, the inherited characteristics seem to satisfy this condition naturally. But here it is more about the application of inheritance, and we have to make sure that our subclass and parent division is accurate.
The subtext of the Richter substitution principle is: Try to use a precise abstract class or interface.
Iii. the principle of single responsibility:
The meaning of a single duty is that the class has a single responsibility and causes a single change of class. Explain, this is also a flexible premise, if we split the class into the smallest functional units, that combination and reuse is much simpler, if a class to do too much, in combination, will inevitably produce unnecessary methods appear, this is actually a kind of pollution.
For example, when we draw a pattern, we use the "point" composition diagram and the "Straight line" composition diagram, which is more flexible. It must be "dot", it can draw any shape, and a line can only draw a pattern with straight lines, it cannot draw a circle at least.
The subtext of a single responsibility is to split the smallest unit and solve the problem of reuse and composition.
Four, the principle of interface isolation:
The interface isolation principle can be said to be a necessary means of a single responsibility, it means to use the function of a single interface as far as possible, without the use of complex functions, comprehensive interface. It is well understood that interfaces are intended to be implemented by subclasses, and if subclasses want to achieve a single function, then the interface must also satisfy a single function.
Conversely, if an interface blends a number of unrelated methods, its subclasses are forced to implement all methods, although some methods are not available at all. This is the interface pollution.
The subtext of the interface isolation principle is: Split, starting from the interface.
V. The principle of dependency inversion:
To understand the dependency inversion principle, you must first understand the traditional solution. The initial program of a face object that is invoked by the caller. That is, the caller decides what method the caller has, and what kind of implementation it is, and the structure will pay a great price when the requirements change, or even overturn the rewrite.
The dependency inversion principle requires that both the caller and the callee rely on abstraction so that there is no direct association or contact between the two, and that the change of one party does not affect the other.
In fact, the dependency inversion and the preceding principles are mutually reinforcing, emphasizing the importance of abstraction.
The subtext of dependency inversion is: abstract programming, decoupling of calls and callee.
Vi. Principles of Dimitri:
The Dimitri principle requires as much encapsulation as possible, as far as possible, to use the low-level access modifiers as much as possible. This is a typical embodiment of encapsulation characteristics.
A class that exposes too many private methods and fields can leave the caller at a loss. And it creates unnecessary code of judgment for the class. So we use the lowest possible access modifier so that the outside world doesn't know what's inside of us. This is also the basic idea of object-oriented. This is an attribute of the Dimitri principle and it is not possible to understand more private information about a class.
In addition, the Dimitri principle requires direct contact between classes as little as possible, two classes of access, through the third mediation class to implement.
The subtext of the Dimitri principle is: Don't talk to strangers, do something to mediate.
Vii. Combinatorial/Aggregate reuse principles:
The implication of this principle is that if you only achieve the purpose of code reuse, try to use composition and aggregation rather than inheritance. Here you need to explain that a composite aggregation is simply a way of referencing other classes, and will not change descent by inheriting the referenced class.
Inheritance is more coupled, such as a parent class that later adds an implementation interface or removes an interface, and that subclass can be a destructive compilation error, but if it's just a combinatorial aggregation, it's just a way of referencing the class, and it's not a huge risk, but it's also reusable.
The subtext of combinatorial aggregation reuse principle is: I just use your method, we are not necessarily the same.

2, in learning the object of the seven major design principles need to pay attention to the following points:
A high cohesion, low coupling and single function "conflict"
In fact, the two are the same thing. Cohesion requires a class to put all the relevant methods together, at first glance is the function is many, but has a "high", is requests to link very tightly the function to put together, namely, from the whole, is one function's ability puts together, therefore, the two are different expression.
A lot of people here understand the compound class, but the compound class is not a cohesion well-structured classes, but a messy set together, is a design error.
(b) Flexibility and declarative type issues for multiple single functional interfaces
If a class implements multiple interfaces, which interface type should the class declare? You should inherit multiple interfaces with an abstract class, and implement the class to inherit the interface. When declaring, the type is an abstract class.
(c) Minimum knowledge principles and the two extremes of intermediary flooding
This is another kind of design mistake. Dimitri principle requires mediation between classes to communicate, but after more classes, will cause the situation of intermediary flooding, this situation, we can consider the intermediary model, with a total intermediary class to achieve.
Of course, design patterns have their own flaws, the Dimitri principle is not perfect, interactive classes are very numerous circumstances, to the appropriate sacrifice design principles.
d the "conflict" of inheritance and combinatorial aggregation reuse principles
Inheritance can also achieve reuse, and that principle is not to abandon inheritance. No.
Inheritance pays more attention to "descent", which is what type. And the combination of aggregation is more focused on the use of "skills." And, in combinatorial aggregation, two classes are partially related to the whole, and combinatorial aggregation can be composed of the skills of multiple classes. Only single inheritance in C # and Java.
The principle is not to tell us not to inherit, all use combinatorial aggregation, but at the point of "reuse", we prefer to use combinatorial aggregation.

Common problems of object-oriented design principles:
1, so many design patterns, to learn and use Mody.
A: We just master the principles of the general, and then learn the commonly used on the line. Not every design pattern is often used in actual development. Because in the final analysis, design mode or architecture, are all for the needs of service, there is no demand business model, can not apply mechanically. When we study, we learn something that is always good, but just to broaden our horizons.
2, design mode is the norm. is not a good program must use design mode.
A: Strictly speaking, a good program follows design principles, not design patterns. Now there are a lot of new evolving patterns, these are due to the emergence of new business reasons, design patterns are not norms, but a reference.
3, the use of design patterns will not increase the difficulty of development.
A: The development phase will be, and will extend the development time. But a project or product from the beginning to the end, development is only a small part of the maintenance and expansion of the cost, the design pattern will appear. Overall, design patterns are designed to reduce development time and cost.