2.0 - Design Patterns seven principles of software architecture design - Single Responsibility Principle

Single Responsibility (Simple Responsibility Pinciple, SRP) means there is reason not to cause more than a class change. Suppose we have a Class responsible for two areas of responsibility, once the demand is changed, modify the code in which a logic responsibilities, may lead to functional responsibilities of another failure. As a result, this leads to two classes Class there is reason to change. How to solve this problem? We are going to use two responsibilities were two Class achieved decoupling. Post-maintenance requirements change independently of each other. This design can reduce the complexity of the class, the class improve readability, increase maintainability of the system, reducing the risk caused by changes. Overall, it is a Class / Interface / Method is only responsible for a duty.

Next, look at a piece of code:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:34
 */
public class Curriculum {
    public void study(String courseName){
        if("直播课".equals(courseName)){
            System.out.println(courseName + "不能快进");
        }else{
            System.out.println(courseName + "可以反复回看");
        }
    }

    public static void main(String[] args) {
        Curriculum curriculum = new Curriculum();
        //不同的职责
        curriculum.study("直播课");
        curriculum.study("录播课");
    }
}

From the above point of view the code, Curriculum assume two classes processing logic. If, now of course be encrypted, and the encryption logic class live and recorded classes are not the same, you must modify the code. And modify the code logic is bound to affect each other easily lead to uncontrollable risks. We were separated for decoupling duties, look at the code, create two classes respectively ReplayCurriculum and LiveCurriculum

code show as below:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:37
 */
public class ReplayCurriculum {
    public void study(String courseName){
        System.out.println(courseName + "可以反复回看");
    }
}

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:37
 */
public class LiveCurriculum {
    public void study(String courseName){
        System.out.println(courseName + "不能快进");
    }
}

 public static void main(String[] args) {
        ReplayCurriculum replayCurriculum=new ReplayCurriculum();
        replayCurriculum.study("可以反复回看");

        LiveCurriculum liveCurriculum=new LiveCurriculum();
        liveCurriculum.study("不能快进");
    }

Business continues to develop, curriculum authority to do. Students can not pay for basic information about the course, students may have to pay to obtain the video stream, namely learning permission. So there are at least two areas of responsibility for the control level courses. We can show responsibility and management responsibilities separated, they are one and the same abstract dependency. A top level interface design, create Curriculum interfaces:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:45
 */
public interface Curriculum {
    //获得基本信息
    String getCourseName();
    //获得视频流
    byte[] getCourseVideo();
    //学习课程
    void studyCourse();
    //退款
    void refundCourse();
}

We can put this interface is split into two interfaces, create an interface ICurriculum and ICurriculumManager: ICurriculum Interface:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:46
 */
public interface ICurriculum {
    String getCourseName();
    byte[] getCourseVideo();
}

ICurriculumManager Interface:

/**
 * @author madongyu
 * @projectName design-pattern-ma
 * @description: TODO
 * @date 2019/6/1815:46
 */
public interface ICurriculumManager {
    void studyCourse();
    void refundCourse();
}

Here we look at the method level of a single design duties. Sometimes, we have to be lazy, a method will usually be written as follows:

 public Curriculum(String name,String address) {
    }

    public Curriculum(String name,String address,boolean bool) {
        if(bool){

        }else {

        }
    }

Obviously, the above Curriculum () methods have had to bear more responsibility, not only can modify the name, you can modify the address, even more, obviously does not meet the single responsibility. So we make the following changes, this method is split into two:

 public Curriculum(String name) {
        name="ma";
    }

    public Curriculum(String address) {
        address="北京";
    }

After this modification, development is simple, easy to maintain them. However, we are in the actual development will depend on project, portfolio aggregation of these relationships, as well as the scale of the project cycle level, technical personnel, the progress of the control, many classes do not meet a single responsibility. However, we are in the process of writing code, as far as possible so that the interface and method for maintaining a single responsibility, for the latter part of the maintenance of our project is of great help.

2.0 - Design Patterns seven principles of software architecture design - Single Responsibility Principle

Guess you like