Discussion on Software Design 3: 30 minutes on Object-Oriented Design Principles

30-minute understanding of Object-Oriented Design Principles

Many people have read the design patterns, but Martin does not have much estimation on the object-oriented design principles (For details, refer to Agile Software Development: Principles, models and practices). In fact, the two are complementary: the design pattern is a specific practical method, and the design principle is the guiding ideology; The design pattern lets you know how, and the design principle lets you know why.

Agile Software Development: Principles, models, and practices: the original book has hundreds of thousands of words, and dozens of pages are introduced to the design principles of object-oriented classes, A friend without patience may not be able to see it. It doesn't matter. Here I will give you a lite version. After reading this blog, you will be able to master these principles and provide some difficult answers to help you better understand them.

1 SRP (single responsibility principle)

This principle seems simple, that isOne class can only assume one responsibility.

But there is a key point here: How is "responsibility" Understood?

According to the Chinese understanding, the responsibilities are divided into two parts: "duty" and "responsibility ". "Role" is what this class is, and "responsibility" is what it is.

For example, if door is an object, its "role" is the door, and its "responsibility" is the door, the door is closed, and the lock "role" is the lock, the "responsibility" is "locking and unlocking ". If the door has the lock function at the same time during design, the door violates the SRP principle.

2 OCP (open and closed Principles)

I believe this is the principle most widely seen by everyone, and many people have explained this as "open to extensions and closed to modifications". More people have summarized it as "adding new functions without modifying code "!

It's amazing to add new functions without modifying the code! But I cannot help wondering: how can I add new functions without modifying the code? Is the code mutating like a creature?

After careful research, I found that these summary people misled me and didn't mean "adding new functions without modifying the code ", it is not the "open to extension, closed to modification" that omitted the subject, but"Extended by callers, closed by callers"

For example, if the door object is called by another object such as people, the door object is called and the people object is called. The door object can be extended to "anti-theft door", "Fire Door", and "escape door", but people do not need to pay attention to the specific door when calling it, you only need to call the "Open and Close" operations for these public doors.

3 LSP (liskov replacement principle)

This seems to be a hard-to-understand principle, but I can give a very easy-to-understand Summary: "the input of subclass cannot be more than the parent class, and the output of subclass cannot be less than the parent class! ".

"Input" refers to the conditions to be given when the class is called., The most common is the function parameter, and the general language can guarantee from the syntax that the parameters of the same subclass and the parent class must be the same; another implicit condition is that "assumptions" or "requirements" must be the same.

A simple example is rectangle and square. According to mathematical definitions, a square is a special rectangle. According to this definition, it seems that a square can be defined as a subclass of a rectangle, but in object oriented design, it does not work, because the side length of a square cannot be set according to the method of setting the length and width of a rectangle, A square requires that the length and width be equal, while a rectangle does not ". This is because the "hypothesis" or "hypothesis" of the subclass is more than the parent class, which violates the LSP principle.

"Output" refers to the result returned after the class is called.. That is, the returned results of the subclass must contain the returned results of the parent class. The returned results can be multiple but must not be fewer.

Why should we meet the LSP principles during design? In fact, it is very simple, because the caller only sees the parent class and does not know which subclass it is, all caller processing is based on the information (including input and output information) provided to the caller by the parent class ).

4 Dip (dependency inversion principle)

This principle seems a little scary. You will understand it in a simple way. In fact, it corresponds to one of the two principles mentioned at the beginning of "Design Pattern":"Interface-based programming, rather than implementation-based programming". (What is the other one ?)

Here, "programming" includes "Caller" and "called" programming. The "Caller" calls the API, and the "called by" performs the specific implementation based on the API.

Note: two of the more confusing concepts similar to "Dependency inversion" are "dependency injection" and "control inversion". For details, refer to the following blog: http://blog.csdn.net/taijianyu/archive/2008/04/28/2338311.aspx

5 ISP (interface isolation principle)

This principle is also very simple, that is, an object should not provide multiple interfaces, and different interfaces should be separated to different objects.

Although the level of the Master cannot be doubted, I still need to doubt that SRP and ISP are essentially a principle, but they are different.

Why? Let's take a look at the SRP principle. It refers to "single responsibility ". So what is the responsibility ultimately reflected in the object? Yes, isn't it an interface! That is to say, if the SRP principle is followed, the interface is naturally isolated.

 

========================================================== ==========

How do I see if it only took 30 minutes? Are you familiar with these principles? If you have any questions, please leave a message.