Java 디자인 모델 프로그래밍에서의 단일 직책 원칙을 간단히 설명하다

단일 직책 원칙: 하나의 종류, 오직 하나의 변화를 일으키는 원인.
왜 단일 직책 원칙이 필요합니까?
만약 한 종류가 여러 가지 이유로 그것을 수정해야 한다면, 한 기능을 수정할 때, 다른 기능에 버그가 생길 수 있기 때문에, 한 종류는 하나의 직책만 있는 것이 가장 좋다.그러나 실제 응용에서는 실현하기 어렵다. 우리는 가능한 한 이 원칙에 부합할 수밖에 없다.
때때로 개발자가 인터페이스를 설계할 때 문제가 있다. 예를 들어 사용자의 속성과 사용자의 행위가 하나의 인터페이스에 놓여 성명된다.이로 인해 업무 대상과 업무 논리가 함께 놓이게 되었다. 그러면 이 인터페이스는 두 가지 직책이 있고 인터페이스 직책이 명확하지 않으며 SRP의 정의에 따라 인터페이스의 단일 직책 원칙에 위배된다.
다음은 예입니다.

package com.loulijun.chapter1; 
  
public interface Itutu { 
  //  
  void setShengao(double height); 
  double getShengao(); 
  //  
  void setTizhong(double weight); 
  double getTizhong(); 
  //  
  boolean chiFan(boolean hungry); 
  //  
  boolean shangWang(boolean silly); 
} 

위의 예에서 이 문제가 존재한다. 키, 체중은 업무 대상에 속하고 그에 상응하는 방법은 주로 사용자의 속성을 책임진다.한편, 밥을 먹고 인터넷을 하는 것은 상응하는 업무 논리로 주로 사용자의 행위를 책임진다.그러나 이것은 이 인터페이스가 도대체 무엇을 하는지 알 수 없는 느낌을 주고 직책이 명확하지 않으며 후기에 유지할 때도 여러 가지 문제를 일으킬 수 있다.
해결 방법: 단일 직책 원칙, 이 인터페이스를 두 직책이 다른 인터페이스로 분해하면 된다
ItutuBO.java:tutu(칠, 만약 인명)의 속성을 담당합니다

package com.loulijun.chapter1; 
  
/** 
 * BO：Bussiness Object，  
 *   
 * @author Administrator 
 * 
 */ 
public interface ItutuBO { 
  //  
  void setShengao(double height); 
  double getShengao(); 
  //  
  void setTizhong(double weight); 
  double getTizhong(); 
} 

ItutuBL.java: 바르는 행위 담당

package com.loulijun.chapter1; 
/** 
 * BL:Business Logic,  
 *   
 * @author Administrator 
 * 
 */ 
public interface ItutuBL { 
  //  
  boolean chiFan(boolean hungry); 
  //  
  boolean shangWang(boolean silly); 
} 

이렇게 하면 인터페이스의 단일한 직책을 실현할 수 있다.그러면 인터페이스를 실현할 때 두 가지 다른 종류가 필요하다
TutuBO.java

package com.loulijun.chapter1; 
  
public class TutuBO implements ItutuBO { 
  private double height; 
  private double weight; 
  @Override 
  public double getShengao() {     
    return height; 
  } 
  
  @Override 
  public double getTizhong() { 
    return weight; 
  } 
  
  @Override 
  public void setShengao(double height) { 
    this.height = height; 
  } 
  
  @Override 
  public void setTizhong(double weight) { 
    this.weight = weight; 
  } 
  
} 

TutuBL.java

package com.loulijun.chapter1; 
  
public class TutuBL implements ItutuBL { 
  
  @Override 
  public boolean chiFan(boolean hungry) { 
    if(hungry) 
    { 
      System.out.println(" ..."); 
      return true; 
    } 
    return false; 
  } 
  
  @Override 
  public boolean shangWang(boolean silly) { 
    if(silly) 
    { 
      System.out.println(" ， ..."); 
      return true; 
    } 
    return false; 
  } 
  
} 

이렇게 하면 명확해진다. 사용자 속성을 수정해야 할 때 ItutuBO라는 인터페이스를 수정하면 TutuBO 클래스에만 영향을 주고 다른 클래스에는 영향을 주지 않는다.
요약:
1. 실제 상황은 우리가'변화를 일으키는 원인'을 미리 예견할 수 없는 경우가 많기 때문에 우리는 경험에 따라 우리의 인터페이스를 구축하고 가능한 한 하나의 인터페이스는 하나의 직책만 할 수 있다.여기서 말하는 것은 인터페이스이다. 클래스는 여러 개의 인터페이스를 계승하고 실현할 수 있기 때문에 단일한 직책을 실현하기 더욱 어렵다.
2. 이전에 쓴 클래스가 이미 여러 가지 변화를 일으킨 원인이 있을 때 우리는 코드 재구성을 하는 것이 가장 좋다.
그러나 단일 직책 원칙을 사용하는 데 문제가 하나 있다.'직책'은 명확한 구분 기준이 없다. 만약에 직책을 너무 세밀하게 구분하면 인터페이스와 실현류의 수량이 급증하고 오히려 복잡도를 높여 코드의 유지보수성을 낮출 수 있다.그래서 이 직책을 사용할 때 구체적인 상황을 구체적으로 분석해야 한다.건의는 인터페이스는 반드시 단일 직책 원칙을 채택하고 유형의 디자인을 실현하는 데 가능한 한 단일 직책 원칙을 해야 하며 가장 좋은 것은 하나의 원인이 하나의 유형의 변화를 일으키는 것이다.