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

This article mainly explains "what are the six principles of object-oriented design". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. let's study and learn what are the six principles of object-oriented design.

Six principles

Back to the point, this is the first article in my series of learning design patterns. This article is mainly about the six principles that object-oriented design should follow. Mastering these principles can help us better understand the concept of object-oriented. can also better understand design patterns. The six principles are as follows:

Principle of single responsibility-- SRP

The principle of opening and closing-OCP

Interior substitution principle-- LSP

The principle of dependency inversion-DIP

Interface isolation principle-ISP

Dimitt principle-- LOD

Principle of single responsibility

The principle of single responsibility, Single Responsibility Principle, or SRP for short. The definition is that there should be one and only one class causes a change to the class, which means that a class has only one responsibility.

For example, in a start-up company, due to the lack of standard labor cost control and process, one person often needs to undertake N responsibilities. An engineer may not only have to meet the requirements, but also write code, and even interview customers. There are several kinds of pans on the back, which are simply expressed in code like this:

Public class Engineer {public void makeDemand () {} public void writeCode () {} public void meetClient () {}}

There seems to be no problem with the code, because that's what we usually write, but after careful reading, we can find that this writing is obviously not in line with the principle of single responsibility, because there is more than one class change. at least three methods can cause class changes, such as one day because of business needs, the method of requirements needs to add a function (such as cost analysis of requirements) Or see that the customer also needs a parameter and so on, so there are many possibilities for class changes, and other classes that reference this class also need to change accordingly. If there are a large number of reference classes, you can imagine how high the cost of code maintenance will be. So we need to split these methods into separate responsibilities, so that a class can be responsible for only one method, and each class can only focus on its own methods.

Advantages of the principle of single responsibility:

The complexity of the class is reduced, and all responsibilities are clearly defined.

The logic becomes simple, the readability of the class is improved, and because the logic is simple, the maintainability of the code is also improved.

The risk of change is reduced because it will only be modified in a single class.

Opening and closing principle

The open-close principle, Open Closed Principle, is the most basic design principle in the Java world, which is defined as:

A software entity such as classes, modules, and functions should be open to extensions and closed to modifications

In other words, a software entity should implement changes through extensions, not by modifying existing code. This is a principle that constrains the current development design for future events of software entities.

In the process of our coding, the requirements change constantly. When we need to modify the code, we should try our best to keep the original code unchanged and expand to meet the requirements.

The best way to follow the open-closed principle is abstraction. For example, in the engineer class mentioned above, we are talking about abstracting the method into a separate class, and each class is responsible for a single responsibility, but in fact, from the point of view of the open-closed principle, a better way is to design the responsibility as an interface, for example, to extract the responsibility method of writing code into the form of interface, at the same time At the beginning of the design, we need to take into account all the factors that may change in the future, for example, the future may be divided into background and front-end functions because of business needs, and then we can design two interfaces at the beginning of the design.

Public interface BackCode {void writeCode ();} public interface FrontCode {void writeCode ();}

If the business of the front-end code changes in the future, we only need to expand the function of the front-end interface, or modify the implementation class of the front-end interface, the background interface and the implementation class will not be affected, this is the benefit of abstraction.

Richter's substitution principle

The Richter substitution principle, whose English name is Liskov Substitution Principle, is defined as

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.

It looks a little tongue-twisting, and it has a simple definition:

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

To put it popularly, as long as the parent class can appear, the subclass can appear, and replacing it with the subclass will not cause any exception. But not the other way around, because the subclass can extend the functionality that the parent class does not have, and the subclass cannot change the original function of the parent class.

As we all know, the three major features of object-oriented are encapsulation, inheritance and polymorphism, all of which are indispensable, but they are not "harmonious". Because inheritance has many disadvantages, when the subclass inherits the parent class, although the code of the parent class can be reused, 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. If the requirement changes, when the subclass overrides the methods of the parent class, other subclasses may need to change accordingly, which to a certain extent violates the principle of encapsulation, and the solution is to introduce the Richter substitution principle.

The Richter substitution principle defines a specification for good inheritance, which contains four meanings:

1. A subclass can implement the abstract methods of the parent class, but it cannot override the non-abstract methods of the parent class.

2. Subclasses can have their own personalities, attributes and methods.

3. The input parameters can be enlarged when the subclass overrides or reloads the method of the parent class.

For example, the parent class has a method, and the parameter is HashMap

Public class Father {public void test (HashMap map) {System.out.println ("parent class is executed.") ;}}

Then the type of the input parameter of the method of the same name of the subclass can be expanded, for example, our input parameter is Map

Public class Son extends Father {public void test (Map map) {System.out.println ("subclass is executed.") ;}}

Let's write a scenario class to test the method execution effect of the parent class.

Public class Client {public static void main (String [] args) {Father father = new Father (); HashMap map = new HashMap (); father.test (map);}}

Result output: the parent class is executed.

Because of the Richter substitution principle, a subclass can appear as long as the parent class can appear, and replacing it with a subclass will not cause any exception. Let's change the code to call the method of the subclass

Public class Client {public static void main (String [] args) {Son son = new Son (); HashMap map = new HashMap (); father.test (map);}}

The running result is the same, because the range of input parameter types of the subclass method is expanded, the subclass passes to the caller instead of the parent class, and the subclass method will never be executed, which is actually correct. If you want the subclass method to execute, you can override the method body.

On the other hand, if the input parameter type range of the subclass is smaller than that of the parent class, for example, the parameter in the parent class is Map and the subclass is HashMap, then the result of executing the above code will be the method body of the subclass. Some people say, isn't that right? Subclasses display their own content. In fact, this is not right, because the subclass does not override the method of the parent class of the same name, the method is executed, which will cause logical confusion, if the parent class is an abstract class, and the subclass is an implementation class, you pass such an implementation class against the intention of the parent class, and it is easy to cause logical confusion, so the input parameters must be the same or enlarged when the subclass overrides or overloads the methods of the parent class.

4. The output can be reduced when the subclass overrides or overloads the method of the parent class, that is to say, the return value is less than or equal to the method return value of the parent class.

Ensuring that programs follow the Richter substitution principle can require our programs to establish abstractions, establish specifications through abstractions, and then expand details with implementation, so it is often interdependent with the open-close principle.

Principle of dependency inversion

The dependency inversion principle, Dependence Inversion Principle, or DIP for short, is defined as:

High-level modules should not rely on underlying modules, both should rely on their abstraction

Abstraction should not rely on details

Details should rely on abstraction

What are the high-level modules and the bottom modules? The indivisible atomic logic is the bottom module, and the reassembly of atomic logic is the high-level module.

In the Java language, abstraction refers to interfaces or abstract classes, neither of which can be instantiated; the details are classes generated by implementing interfaces or inheriting abstract classes, that is, implementation classes that can be instantiated. 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 interface, which is commonly known as interface-oriented programming.

Let's take a singer singing as an example, for example, a singer sings a mandarin song, which is expressed in code:

Public class ChineseSong {public String language () {return mandarin song;}} public class Singer {/ / singing method public void sing (ChineseSong song) {System.out.println ("singer" + song.language ());}} public class Client {public static void main (String [] args) {Singer singer = new Singer (); ChineseSong song = new ChineseSong (); singer.sing (song);}}

Run the main method, and the result is output: the singer sings the mandarin song

Now, we need to add a little difficulty to the singer, such as singing English songs, in this category, we find it very difficult to do. Because our Singer class depends on a specific implementation class ChineseSong, some people may say that we can add a method, but in this way we have modified the Singer class. If we need to add more songs in the future, won't the singer class be modified all the time? In other words, the dependency class is already unstable, which is obviously not what we want to see.

So we need to optimize our solution with the idea of interface-oriented programming and change it to the following code:

Public interface Song {public String language ();} public class ChineseSong implements Song {public String language () {return "sing Mandarin songs";}} public class EnglishSong implements Song {public String language () {return "sing English songs";}} public class Singer {/ / singing method public void sing (Song song) {System.out.println ("singer" + song.language ()) }} public class Client {public static void main (String [] args) {Singer singer = new Singer (); EnglishSong englishSong = new EnglishSong (); / / sing English song singer.sing (englishSong);}}

We separate the song into an interface Song, and each song category implements this interface and rewrites the method. In this way, the singer's code does not need to be changed. If you need to add the type of song, you only need to write one more implementation class to inherit Song.

Through such interface-oriented programming, our code has better expansibility, but also reduces the coupling and improves the stability of the system.

Interface isolation principle

Interface isolation principle, Interface Segregation Principle, or ISP for short, is defined as:

The client should not rely on interfaces it does not need

It means that the client can provide whatever interface is needed and remove the unneeded interface, which requires refinement of the interface to ensure the purity of the interface. To put it another way, dependencies between classes should be based on the smallest interface, that is, a single interface.

You may wonder, isn't it the principle of single responsibility to establish a single interface? In fact, the principle of single responsibility requires that the responsibility of the class and interface is single, focusing on responsibility, and the interface of one responsibility can have multiple methods, while the principle of interface isolation requires that the method of the interface is as few as possible and the module is as simple as possible. If you need to provide a lot of modules to the client, it is necessary to define multiple interfaces accordingly, and do not define all module functions in one interface. That would look bloated.

For example, today's smartphones are very developed, almost everyone's social state. In our young people's view, a good smartphone should be cheap, good-looking, and feature-rich. From this, we can define an abstract interface ISmartPhone for smartphones. The code is as follows:

Public interface ISmartPhone {public void cheapPrice (); public void goodLooking (); public void richFunction ();}

Next, we define an implementation class of the mobile interface to implement these three abstract methods

Public class SmartPhone implements ISmartPhone {public void cheapPrice () {System.out.println ("this phone is cheap ~");} public void goodLooking () {System.out.println ("this phone looks good ~");} public void richFunction () {System.out.println ("this phone has so many features");}}

Then, we define a user's entity class User, and define a constructor, which is passed in with ISmartPhone as a parameter. At the same time, we also define a method usePhone that is used to call the interface.

Public class User {private ISmartPhone phone;public User (ISmartPhone phone) {this.phone = phone;} public void usePhone () {phone.cheapPrice (); phone.goodLooking (); phone.richFunction ();}}

As you can see, when we instantiate the User class and call its method usePhone, the method body information of the three methods of the mobile interface will be displayed on the console. This design does not seem to be a big problem, but we can think carefully about whether the design of the ISmartPhone interface has reached the optimal level. Unfortunately, the answer is no, the interface can actually be further optimized.

Because in addition to young people, middle-aged business people are also using smartphones, in their view, smartphones do not need rich features, and do not even have to consider whether they are cheap (money is wayward). Because successful people are busy, most of the requirements for smartphones are atmospheric in appearance and simple in function, which is the characteristic of a good smartphone in their heart. The ISmartPhone interface we defined is not applicable, because our interface defines that a smartphone must meet three features, and if you implement this interface, you must implement all three methods, while for business people, the methods we define only match the appearance and can be reused. You might say, I can rewrite an implementation class, only the methods that implement the appearance, and the other two methods are empty and write nothing, isn't that all right? But this doesn't work either, because User refers to the ISmartPhone interface, it calls three methods, and you only implement two, so there are two fewer printed messages. Just depending on the appearance, how do users know if the smartphone meets their expectations?

At this point of analysis, we probably understand that, in fact, the design of ISmartPhone is flawed and too bloated. According to the principle of interface isolation, we can split the smartphone interface according to different characteristics. In this way, the function of each interface will become single, ensuring the purity of the interface, and further improving the flexibility and stability of the code.

Demeter's principle

The Dimitt principle, Law of Demeter, or LoD for short, is also known as the least knowledge principle. It describes the rules as follows:

An object should know the least about other objects.

In other words, a class should know least about the classes that it needs to couple or call. The closer the relationship between classes and the greater the degree of coupling, the greater the impact of class changes on their coupled classes. This is also our core design-oriented principle: low coupling, high cohesion.

There is another explanation for Dimitt's rule: communicate only with direct friends.

What is a direct friend? Each object must have a coupling relationship with other objects, and the coupling of two objects becomes a friend relationship. There are many types of this relationship, such as composition, aggregation, dependency 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.

For example, before PE class, the teacher asked the monitor to go to the gym to get 20 basketballs and use them later in class. According to this scene, we can design three classes: Teacher (teacher), Monitor (monitor) and BasketBall (basketball), as well as the method of issuing command command and the method of playing basketball takeBall.

Public class Teacher {/ / order the monitor to get the ball public void command (Monitor monitor) {List ballList = new ArrayList (); / / initialize the basketball number for (int I = 0 Ting I)

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.