[Zen Reading Notes in design mode] 001 _ six principles of design mode (1): single Responsibility Principle)

Preface

The Zen of design patterns is tied to this book. When I went to the library to borrow a book in the next semester of my junior year, I saw a new book with a title containing the word "Zen, at that time, he was infatuated with Steve Jobs. Therefore, whatever the messy content it writes, you can use it to get it back to the dormitory. Next, during the summer vacation, I went to Kingdee for an internship and read this book with a strong mentality of dressing. During the two-month internship, this book was basically not flipped over. On the contrary, I read the "love of Hawthorn Tree" that was on fire. After the internship, I returned my book.

Today, I have been working for nearly a year and a half. Before that, when I tried to pick up this book and read it, I always felt that I was not in a hurry. Now I think it seems like the fire is approaching, and I have a strong desire for the design model and a strong demand. Today, I have to read this book honestly.

 

Single Responsibility Principle

1When explaining this principle, the author mentioned the single responsibility for the two designs: interface design and class design. The author suggested that the interface design should be subject to a single responsibility, and the class design should be changed for only one reason.

2The advantage brought by the author's summary of the single responsibility principle is that (I think the author's terms are boring here. I guess I can summarize them myself for reference ):

A. The complexity of classes is reduced, and all responsibilities are clearly defined;

B. improved readability;

C. Improved maintainability;

D. Reduce the risks of chain reactions caused by changes (this is a reality. If there is a single responsibility, fewer changes will be caused, and the risks of chain reactions will be reduced );

3The author believes that the difficulty of a single responsibility principle is the division of duties.

In this regard, I personally agree that the so-called responsibilities are difficult to divide.

Let me make a metaphor. We have developers and test engineers talking about the role of software jobs. However, please observe your colleagues and yourself. When you are a development engineer, you also work as a test engineer. When you are a test engineer, you also work as a Development Engineer (which is less likely ).

Therefore, when designing our software operating system, we can design development engineers and test engineers as follows: the development engineers and test engineers in the Rules are strictly independent interfaces with a single responsibility. In reality, the development engineers and test engineers have mixed responsibilities. Of course, it is best to have only one factor for the classes with mixed responsibilities to cause changes.

-Above-