Design Mode - Single Responsibility Principle Software Design Principles 2-

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, we look at the code examples, or use the curriculum, for example, our courses are live and taped class lesson. Live classes can not fast-forward and rewind, recording and broadcasting can be arbitrarily repeated viewing, functional responsibilities are not the same. Or create a Course categories: 

. 1  Package com.lch.test.simpleresponsibility;
 2  
. 3  / ** 
. 4  * single responsibility
 . 5   * / 
. 6  public  class Course, {
 . 7      public  void Study (String CourseName) {
 . 8          IF ( "Live Course" .equals (CourseName)) {
 . 9              System.out.println (CourseName + "not fast forward" );
 10          } the else {
 . 11              System.out.println (CourseName + "can be repeatedly look back" );
 12          }
 13      }
 14 }
1 package com.lch.test.simpleresponsibility;
2 
3 public class SimpleResponsibilityTest {
4     public static void main(String[] args) {
5         Course course = new Course();
6         course.study("直播课 ");
7         course.study("录播课 ");
8     }
9 }

From the above point of view the code, Course class assume two 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 decoupling of segregation of duties, look at the code, create two classes respectively ReplayCourse and LiveCourse:

1 package com.lch.test.simpleresponsibility;
2 
3 public class LiveCourse {
4     public void study(String courseName){
5         System.out.println(courseName + "不能快进看");
6     }
7 }
1 package com.lch.test.simpleresponsibility;
2 
3 public class ReplayCourse {
4     public void study(String courseName){
5         System.out.println(courseName+"可以反复看");
6     }
7 
8 }

Calling code

 1 package com.lch.test.simpleresponsibility;
 2 
 3 public class SimpleResponsibilityTest2 {
 4     public static void main(String[] args) {
 5        LiveCourse liveCourse = new LiveCourse();
 6        liveCourse.study("直播课");
 7        ReplayCourse replayCourse = new ReplayCourse();
 8        replayCourse.study("录播课");
 9     }
10 }

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 ICourse interfaces:

. 1  Package com.lch.test.simpleresponsibility;
 2  
. 3  public  interface Icourse {
 . 4      // basic information 
. 5      String getCourseName ();
 . 6  
. 7      // obtain a video stream 
. 8      byte [] getCourseVideo ();
 . 9  
10      // learning courses 
11      void studyCourse ();
 12 is  
13 is      // refund 
14      void refundCourse ();
 15 }

This interface can be split into two interfaces, create an interface ICourseInfo and ICourseManager, ICourseInfo interfaces:

. 1  Package com.lch.test.simpleresponsibility;
 2  
. 3  public  interface ICourseInfo {
 . 4      // basic information 
. 5      String getCourseName ();
 . 6  
. 7      // obtain a video stream 
. 8      byte [] getCourseVideo ();
 . 9 }
. 1  Package com.lch.test.simpleresponsibility;
 2  
. 3  public  interface ICourseManager {
 . 4      // learning course 
. 5      void studyCourse ();
 . 6  
. 7      // refund 
. 8      void refundCourse ();
 . 9 }

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:

1 private void modifyUserInfo(String userName, String address) {
2         userName = "Tom";
3         address = "Changsha";
4     }
1  private void modifyUserInfo(String userName, String address, boolean bool) {
2         if (bool) {
3         } else {
4             userName = "Tom";
5             address = "Changsha";
6         }
7     }

Obviously, the above modifyUserInfo () methods have had to bear more responsibility, either modify userName, 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:

1   private void modifyUserName(String userName) {
2         userName = "Tom";
3     }
4 
5     private void modifyAddress(String address) {
6         address = "Changsha";
7     }

After this modification, development is simple, easy to maintain them. However, we are in the actual development will depend on project, portfolio, polymerization scale, period level of these relations, there are still projects, 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

Guess you like

Origin www.cnblogs.com/enjoyjava/p/11333242.html