The six principles of object-oriented

Now the mainstream language of programming is basically object-oriented. such as C#,c++,java. When we use it, we have constructed a class. But often because of our internal or external design problems in the class, resulting in the object-oriented language, is the process-oriented logic, and even maintenance is extremely difficult. Every time you add or modify a function to change a lot of code, on thin ice. The main purpose of the six-object-oriented principle is how to design the class and make good use of the object-oriented features.

1) Single duty principle

A class always has only one responsibility.

A set of software is like a team, and each class is a member of the team. If the team wants steady development. These classes will have their own roles and clear division of labor. If there is confusion between the functions of the classes, the overall structure of the software can be very confusing. As a sentence in management, if a responsibility is assigned to each employee, then there is no responsibility for the responsibility of the employee. The concept of this principle is very simple and very basic. Many people do not learn object-oriented thinking, but often write code after they will not consciously adhere to this principle. Ps: In accordance with the principle of single responsibility, often encounter the issue of responsibility proliferation. What is responsibility diffusion? Here is a simple, in the journal Life, we in the classification of responsibilities, found a lot of ordinary non-valued responsibilities, but these responsibilities can not be ignored. Then it accumulates in succession, and finally the class is endless (interested readers can refer to the Long tail theorem). In order to solve this problem, we need to have some classes, his responsibilities are more comprehensive (similar to "other"). Similar to a helper class. But this class can not be too complicated, otherwise we should consider how to separate this class. When is the complexity of this class going to happen and we should split it? This requires the programmer to judge by the complexity of the software itself, without a unified standard.

2) Richter replacement principle

"Inheritance should ensure," any property proved about Supertype objects also holds for subtype objects. "

--"inheritance must ensure that the nature of the superclass is still true in the subclass"

This principle is mainly to reflect the object-oriented "inheritance" characteristics to be proposed. Its main thrust is that where the base class can be used, it is bound to be able to use its subclasses transparently, and ensure that there are no errors. To ensure this transparent and non-discriminatory use, subclasses should not arbitrarily rewrite the non-abstract methods that are already defined by the parent class when used. Because these non-abstract methods are similar to a function or contract, when the parent class maintains such a contract, the subclass should also follow and guarantee the attribute, rather than modifying the attribute. When we write code, if a parameter is set to the base class (or interface, abstract class), then we send the subclass into, as normal use. Because the base class is relative to the parent class, it is just a richer, more specific, more detailed representation. Instead of appearing, there is no problem in passing the parent class to run a method, but the incoming subclass runs with an error. This is understandable in everyday life, as the car is a parent, and he has trucks and cars underneath. Under the car there are hatchback, three saloon and other different inheritance. But no matter what kind of car (parent) functions, for his sub-class (truck or car) should have the same function, rather than the opposite function. So that subclasses of subclasses (in this case the hatchback) should also have the same function as cars.

In our code, it is easy to make a copy of the parent class's method, and the parent class's method changes, and the method that does not take into account the subclass needs to be changed accordingly, causing the code to get an error. In layman's point, it can be understood that subclasses are inherited from the parent class. He should also same strain from the parent class in various functions. And should not be arbitrarily changed.

Why should Ps be called the Richter replacement principle? This is because the first person to propose this theory is the surname of Liskov. This is a rare thing in a computer named after a surname.

3) Least know the principle

Your immediate friends. (The second time has quoted English, is not very powerful 23333)

always talk to only your friends.

At the beginning of our learning program, we were told to follow the "high cohesion, low coupling". And OO also "encapsulation" as one of the basic characteristics of the object. The least known principle embodies the phrase "high cohesion, low coupling".

(1) Low coupling: A class for its own classes, the less you know the better. Do not let a class depend on too many classes. Otherwise, this class is very much affected by the outside world, and because of this kind of influence to change its own code (to adapt itself).

(2) High cohesion: the implementation logic is encapsulated inside the class, and information outside the public method is not easily exposed to the outside world. This is because the public after the external, equivalent to a contract, a promise. You want to be in the back of the implementation, constantly to be compatible with this public, to prevent the code that calls it does not error. It may be a bit abstract, here's an example. In many people's request to the other party, there is one, social relations do not complicate. Why is that? Because a person if his relationship with the outside world is more complex, he is more unstable, not afraid of people looking for trouble, timid looking for someone. Perhaps his nature is good, but the surrounding Dragon Fish mixed, Zooey always have something. The best way to avoid this problem is to be a quiet, handsome one from the start.

4) Interface Isolation principle

The dependency of a class on another class should be based on the smallest interface.

An interface definition is too bloated, then each implementation class that represents him has to consider all the implementation logic. If a class implements an interface, which means that the class carries all the functions of the interface, maintaining these functions becomes its own responsibility. This virtually increases the burden of a class.

Here are two points to explain:

(1) The interface definition is small, but there are limits. The refinement of the interface can increase flexibility, but it complicates the design by over-refinement. The usage of the interface is not high, and the maintenance cost of the code is improved. The extreme manifestation of this is that each interface contains only one method, which is obviously inappropriate.

(2) Distinction between the principle of interface isolation and the single principle

Common denominator: All are as narrow as possible to the scope involved.

The difference: The single principle mainly refers to the encapsulation nature. He was targeting a class, a method, which was considered from the object's point of view. The principle of interface isolation refers to the degree to which coupling between classes should be maintained. He is targeting relationships between classes (objects) and classes (objects). If the single principle refers to pure thought, then interface isolation refers to the simple social relations.

5) Dependency substitution principle

The name of this principle is more bluffing, so let's look at what his content is. There are two classic descriptions of this principle in design mode:

(1) High-level modules should not rely on the underlying modules. Both should be dependent on abstraction.

(2) abstraction should not depend on detail, and detail should be dependent on abstraction.

The implication of these two words is that high-level modules should not rely on the underlying module. The two should be linked by abstract things (abstract things refer to interfaces or abstract classes). Second, an abstract class or an interface should not rely on an implementation class. Instead, these implementation classes should rely on the setting of this abstract class.

The popular point is that there should be no direct call relationship between modules (this is the old invocation relationship), and both should be programmed by an interface-oriented (or understood as a set-oriented contract). These contracts and interfaces should not be set up from the underlying modules. These underlying modules should instead adhere to these contracts. Because the contract (abstract class, interface) is not changed, that is more stable, relative to which implementation code. So the dependency substitution principle is also called interface-oriented programming or contract-oriented programming. The intention is to adjust the original dependency relationship, re-set.

6) Opening and closing principle

Open and close principle refers to: a software, a set of systems after the development, when there is an increase or modify the requirements, should be opened to expand the code, the modification of the original code closed.

once the class is determined, it should no longer be modified for its functionality. This is the most important and core principle in object-oriented design. What is our biggest concern after the program is released? Is the change in demand, and once the requirements change, you need to change the code. Most bugs are often introduced at this time. Because of the changes in the code, we tend to focus on how to solve the current bug, but did not pay attention to because of this modification, the impact of the original design.

This principle does not have specific guidance requirements, is the fundamental of the five principles of the front.

PS, these six object-oriented principles are not a question of whether and not, nor is it a question of compliance and non-compliance. But to abide by the more and less the problem of compliance. I have also stressed many times in the article, we should be careful to grasp a degree in the design. Admittedly adhering to these principles as much as possible makes it easier to maintain code. But the maintenance granularity is very fine, the design and the development cost that need is multiplied, this obviously is trifles. , the object-oriented development principle can be shown from the following coordinate chart, regardless of which dimension, his value should not be too full, or even overflow, of course, not very low, to maintain an appropriate degree.

The six principles of object-oriented