Single accusation principle of design pattern principle and accusation of Design Pattern Principle

Single accusation principle of design pattern principle and accusation of Design Pattern Principle

Definition: there should be no more reasons for class changes.In general, a class is only responsible for one responsibility.

Problem:Class T has two different responsibilities: Class P1 and class P2. When the class T needs to be modified because of the change in the responsibility P1 requirement, it may lead to the failure of the originally running responsibility P2 function.

Solution:Follow the single responsibility principle. Create two classes T1 and T2 respectively, so that T1 completes the responsibility P1 function, and T2 completes the responsibility P2 function. In this way, when the class T1 is modified, the responsibility P2 will not be at risk of failure. Similarly, when the class T2 is modified, the responsibility P1 will not be at risk of failure.

When talking about the single responsibility principle, many people will not care about it. Because it is too simple. Even if experienced programmers have never read design patterns or have never heard of a single responsibility principle, they will consciously abide by this important principle when designing software because it is common sense. In software programming, no one wants to modify a function to cause other functions to fail. To avoid this problem, follow the single responsibility principle. Although the single responsibility principle is so simple and is considered common sense, even the code written by experienced programmers will violate this principle. Why does this happen? Due to the proliferation of duties.For some reason, responsibility P is divided into responsibility P1 and P2 with finer granularity.

For example, class T is only responsible for one responsibility P, so the design conforms to the single responsibility principle. Later, for some reason, the requirement may have changed. Maybe the realm of the program designer has been improved, and the responsibility P needs to be subdivided into the granularity and responsibility P1, P2, in this case, if the program follows the single responsibility principle, the class T should also be divided into two classes T1 and T2, responsible for P1 and P2 respectively. However, it takes too much time to write the program. Therefore, it is a good choice to simply modify the class T to take charge of two responsibilities, although this is contrary to the single responsibility principle. (The risk lies in the uncertainty of responsibility diffusion, because we will not think of this responsibility P. In the future, it may spread to P1, P2, P3, P4 ...... Pn. Remember to refactor the code immediately before the responsibility spreads beyond our control .)

For example, a class is used to describe the Animal breathing scenario:

Class Animal {public void breathe (String animal) {System. out. println (animal + "breathing air") ;}} public class Client {public static void main (String [] args) {Animal animal = new Animal (); animal. breathe ("Ox"); animal. breathe ("goat"); animal. breathe ("pig ");}}

Running result:

Cattle breathe air sheep breathe air pigs breathe air

After the program went live, it was found that not all animals breathe in the air. For example, fish breathe in water. If the modification follows the single responsibility principle, the Animal type must be subdivided into the Terrestrial type and the Aquatic type of Aquatic animals. The Code is as follows:

Class Terrestrial {public void breathe (String animal) {System. out. println (animal + "breathing air") ;}} class Aquatic {public void breathe (String animal) {System. out. println (animal + "breathing water") ;}} public class Client {public static void main (String [] args) {Terrestrial terrestrial = new Terrestrial (); terrestrial. breathe ("Ox"); terrestrial. breathe ("goat"); terrestrial. breathe (""); Aquatic aquatic = new Aquatic (); aquatic. breathe ("fish ");}}

Running result:

Cattle breathe air sheep breathe air pigs breathe air fish breathe water

We will find that if this modification costs a lot, in addition to breaking down the original class, we also need to modify the client. While directly modifying the class Animal to achieve the goal violates the single responsibility principle, the cost is much lower. The Code is as follows:

Class Animal {public void breathe (String animal) {if ("fish ". equals (animal) {System. out. println (animal + "breathing water");} else {System. out. println (animal + "breathing air") ;}} public class Client {public static void main (String [] args) {Animal animal = new Animal (); animal. breathe ("Ox"); animal. breathe ("goat"); animal. breathe ("pig"); animal. breathe ("fish ");}}

We can see that this modification method is much simpler. But there is a hidden danger: One day, you need to change the breathe method of the Animal class to divide the fish into fresh water and sea water, modifications to the original code pose risks to calling "pig", "Ox", "goat", and other related functions, maybe one day, you will find that the program running turns to "cow breathing water. This modification method directly violates the single responsibility principle at the code level. Although it is the simplest to modify, it has the greatest potential. There is also a way to modify:

Class Animal {public void breathe (String animal) {System. out. println (animal + "breathing air");} public void breathe2 (String animal) {System. out. println (animal + "breathing water") ;}} public class Client {public static void main (String [] args) {Animal animal = new Animal (); animal. breathe ("Ox"); animal. breathe ("goat"); animal. breathe ("pig"); animal. breathe2 ("fish ");}}

We can see that this modification method does not change the original method, but adds a new method to the class, which violates the single responsibility principle, but at the method level, it is in line with the single responsibility principle, because it does not touch the original method code. The three methods have their own advantages and disadvantages. In actual programming, which one is used? In fact, this is really hard to say, it needs to be determined according to the actual situation. My principle is: only when the logic is simple enough can the single responsibility principle be violated at the code level; only when the number of methods in the class is small enough can the single responsibility principle be violated at the method level;

For example, in this example, it is too simple. It has only one method, so whether it is a violation of a single responsibility principle at the code level or a violation at the method level, will not cause too much impact. Classes in practical applications are much more complex. If a class needs to be modified due to the spread of duties, it is better to follow the single responsibility principle unless the class is very simple.

The original advantages of following a single responsibility are:

• It can reduce the complexity of a class. A class is only responsible for one responsibility, and its logic is certainly much simpler than being responsible for multiple responsibilities;
• Improve readability and maintainability of the system;
• The risk caused by changes is reduced, and changes are inevitable. If the single responsibility principle is followed, when a function is modified, the impact on other functions can be significantly reduced.

One thing to note is that the single responsibility principle is not only exclusive to the object-oriented programming ideology. As long as it is a modular program design, it applies to the single responsibility principle.

Reproduced http://blog.csdn.net/zhengzhb/article/details/7278174