Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces in detail "what are the six principles of Java object-oriented design". The content is detailed, the steps are clear, and the details are handled properly. I hope that this article "what are the six principles of Java object-oriented design" can help you solve your doubts.

Principle of single responsibility

The single responsibility principle is defined as that as far as a class is concerned, there should be only one reason for its change. In other words, a class should be responsible for only one thing. If a class is responsible for two different things, method M1 and method M2, when the M1 method changes, we need to modify the M1 method of this class, but at this time it may cause the M2 method not to work. This is not what we expected, but it is likely to happen because of this design. So at this time, we need to separate the M1 method and M2 method into two classes. Let each class focus only on its own methods.

The benefits of the single responsibility principle are as follows:

Can reduce the complexity of the class, a class is only responsible for one responsibility, so the logic is much simpler to improve the readability of the class, and the maintainability of the system, because there are no other strange ways to interfere with our understanding of the meaning of this class. When there is a change, the impact of change can be minimized, because only changes will be made in this class.

Opening and closing principle

The principle of opening and closing, like the principle of single duty, is a very basic and generally common sense principle. The definition of the open-close principle is that objects (classes, modules, functions, etc.) in the software should be open for extensions, but closed for modifications.

When the requirements change, we need to modify the code, at this time we should try to extend the original code, rather than modify the original code, because this may cause more problems.

This principle, like the principle of single responsibility, is a principle that everyone thinks so but does not specify how to do it.

The opening and closing principle we can ensure it in a way, we build the framework with abstraction and extend the details with implementation. In this way, when a change occurs, we directly use the abstract to derive a concrete class to implement the change.

Richter's substitution principle

The Richter scale substitution principle is a very useful concept. His definition

If for every object o1 of type T1, there is an object of type T2 such that all program P defined by T1 does not change its behavior when all objects o1 are replaced by O2, then type T2 is a subtype of type T1.

This is a bit complicated, but there is actually a simple definition.

All references to the base class must be able to transparently use the objects of its subclasses.

The Richter substitution principle is popularly said that subclasses can expand the function of the parent class, but can not change the original function of the parent class. He has the following meanings:

Subclasses can implement the abstract methods of the parent class, but cannot override the non-abstract methods of the parent class.

Subclasses can add their own unique methods.

When the method of the subclass overloads the method of the parent class, the formal parameter of the method is more relaxed than the input parameter of the method of the parent class.

When the method of the subclass implements the abstract method of the parent class, the return value of the method is stricter than that of the parent class.

The Richter substitution principle requires this because inheritance has many disadvantages. Although it is a method of reusing code, inheritance violates encapsulation to some extent. The properties and methods of the parent class are transparent to the subclass, and the subclass can modify the members of the parent class at will. This also leads to the failure of other subclasses to work properly when the subclass overrides the methods of the parent class if the requirements change. So the Richter substitution rule was proposed.

Ensuring that programs follow the Richter substitution principle can require our programs to establish abstractions, establish specifications through abstractions, and then use implementations to expand the details. Yes, the Richter substitution principle and the opening and closing principle are often interdependent.

Principle of dependency inversion

The principle of dependency inversion refers to a special way of decoupling, so that high-level modules should not rely on the implementation details of low-level modules, and dependency modules are reversed. This is also a difficult definition, which can be put simply

High-level modules should not rely on the underlying modules, and both should rely on their abstractions, not on details, but on abstractions.

In Java, abstraction refers to interfaces or abstract classes, neither of which can be instantiated. The details are the implementation class, that is, the class that implements the interface or inherits the abstract class. He can be instantiated. The high-level module refers to the calling end, and the underlying module is the concrete implementation class. In Java, the principle of dependency inversion means that the dependency between modules occurs through abstraction, and there is no direct dependency relationship between classes, which is realized through interfaces. This is commonly known as interface-oriented programming.

We have an example below to illustrate this problem. This is an example of workers repairing things with hammers. Our code is as follows:

Public class Hammer {

Public String function () {

Return "fix things with a hammer"

}

}

Public class Worker {

Public void fix (Hammer hammer) {

System.out.println ("worker" + hammer.function ())

}

Public static void main (String [] args) {

New Worker (). Fix (new Hammer ())

}

}

This is a very simple example, but if we want to add a new function, workers use screwdrivers to repair things, in this category, we find it very difficult to do. Because our Worker class relies on a concrete implementation class, Hammer. So we use the idea of interface-oriented programming and change it to the following code:

Public interface Tools {

Public String function ()

}

Then our Worker relies on other detail classes through this interface. The code is as follows:

Public class Worker {

Public void fix (Tools tool) {

System.out.println ("worker" + tool.function ())

}

Public static void main (String [] args) {

New Worker (). Fix (new Hammer ())

New Worker (). Fix (new Screwdriver ())

}

}

Our Hammer class implements this interface with the Screwdriver class

Public class Hammer implements Tools {

Public String function () {

Return "fix things with a hammer"

}

}

Public class Screwdriver implements Tools {

@ Override

Public String function () {

Return "fix things with a screwdriver"

}

}

In this way, through interface-oriented programming, our code has a high expansibility, reduces the coupling between the code, and improves the stability of the system.

Interface isolation principle

The definition of the interface isolation principle is

The client should not rely on interfaces that he does not need

To put it another way, dependencies between classes should be based on the smallest interface. This seems to be more difficult to understand. Let's illustrate it with an example. We know that in Java, a concrete class implements an interface, so it is necessary to implement all the methods in the interface. If we have a class An and a class B that depend on interface I, class B is an implementation of dependence on class A, which has five methods. But class An and class B are only dependent on method 1Magne2 and 3, and then class C and class D are dependent on interface I, class D is the implementation of dependence on class C, but they are dependent on method 1mem4 and 5. Then it is necessary to implement the interface, class B should have methods 4 and 5 that he does not need, and class D will implement methods 2 and 3 that he does not need. This is simply a disaster design.

So we need to split the interface, that is, divide the interface into the smallest interface that satisfies the dependency, and class B and class D do not need to implement interface methods that have nothing to do with them. For example, in this example, we can split the interface into three, the first is only the interface of method 1, the second interface contains 2jue 3 methods, and the third interface contains 4je 5 methods. In this way, our design meets the principle of interface isolation.

The above design ideas can be composed of SOLID with the first letter of English, and programs that meet these five principles are also known as meeting the SOLID criteria.

Demeter's principle

The Dimitt principle is also known as the minimum knowledge principle, his definition

An object should have a minimal understanding of other objects.

Because the closer the relationship between classes, the greater the degree of coupling, when one class changes, the greater the impact on another class, so this is also the general principle of software programming that we advocate: low coupling, high cohesion. There is a simpler definition of Demeter's rule.

Communicate only with direct friends. First of all, let's explain what a direct friend is: each object is coupled with other objects, and as long as there is a coupling relationship between two objects, we say that the two objects are friends. There are many ways of coupling, such as dependence, association, combination, aggregation and so on. Among them, we call the classes in the member variables, method parameters and method return values as direct friends, while the classes that appear in local variables are not direct friends. In other words, a strange class had better not appear inside the class as a local variable.

Here we can use a real-life example to explain. For example, if we need a CD, we may go to the video store and ask the boss if he has the CD we need. The boss says he doesn't have it now. Just wait for you to pick it up sometimes. Here we don't need to care about where and how the boss got the CD, we only communicate with the boss (direct friends). As for the CD that the boss gets from his friends, we don't care, we don't communicate with the boss's friends (strangers). This is one of Dimitt's applications. To put it bluntly, it is a way of intermediary. We use the boss as an intermediary to get in touch with the people who actually provide CD.

After reading this, the article "what are the six principles of Java object-oriented Design" has been introduced. If you want to master the knowledge of this article, you still need to practice and use it. If you want to know more about the article, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.