디자인 모델 원칙 편: (1) 단일 직책 원칙 -- 단일 책임 원칙

위의 글 은 디자인 모델 에서 지 켜 야 할 디자인 원칙 을 언급 하고 디자인 모델 에서 지 켜 야 할 6 대 원칙 을 제시 했다.
       다음 글 은 주로 단일 직책 원칙 을 토론 한다.
             단일 직책 원칙 (SRP):
                         클래스 변경 을 초래 하 는 원인 보다 더 많은 것 은 존재 하지 마라.쉽게 말 하면 하나의 유형 이나 인 터 페 이 스 는 하나의 '직책' 만 책임 지 는 것 이다.
              만약 에 한 가지 이상 의 직책 이 있다 면 이런 직책 은 결합 된다. 이런 디자인 은 매우 취약 하 다. 왜냐하면 직무 를 맡 기 때문이다.
              변 화 는 다른 직책 에 영향 을 주 고 재 활용 성에 영향 을 줄 수 있다.
                          여기 에는 클래스 나 인터페이스의 '직책' 에 대한 이해 가 필요 하 다. SRP 는 '직책' 을 '변화의 원인' 으로 이해 하고 N 이 있 을 때
              동기 가 종 류 를 바 꿀 때 이런 종 류 는 SRP 원칙 을 위반 한다.
                       Tips: 여 기 는 당신 만 이 진정 으로 클래스 를 수정 할 때 SRP 원칙 을 위반 합 니 다. 단지 추측 일 뿐, 그렇지 않 습 니 다.
                실제 지불 의 행동 은 하나의 원칙 을 위반 하 는 것 이 아니다.
             단일 직책 원칙 (SRP) 장점:
                1. 유형의 복잡 도 를 낮 출 수 있다.
                2. 클래스 의 가 독성 을 향상 시 키 고 시스템 의 유지 가능성
                3. 변경 시 다른 기능 에 미 치 는 영향 감소 (변경 불가피)
               동물 이 먹 는 것 에 관 한 문제.
                      동물 이 먹 는 것 을 묘사 하 는 종 류 를 만 듭 니 다:

package com.kiritor; /**  * @author Kiritor  *       */ class Animal {    public void eatFood(String name)    { 	   System.out.println(name+"  ");    } }  public class Client { 	public static void main(String[] args) { 		Animal animal = new Animal(); 		animal.eatFood(" "); 		animal.eatFood(" "); 	} 	 } 

               그런데 여기 문제 가 생 겼 어 요. 모든 동물 이 풀 을 먹 는 것 도 아니 고 육식 동물 도 있어 요.단일
      원칙 적 인 상황 에서 우 리 는 동물 류 를 육식 성과 채식 성 으로 세분 해 야 한다.

class AnimalMeat { 	 public void eatFood(String name) 	   { 		   System.out.println(name+"  "); 	   } } class AnimalGlass { 	 public void eatFood(String name) 	   { 		   System.out.println(name+"  "); 	   } }  public class Client { 	public static void main(String[] args) { 		AnimalGlass animal = new AnimalGlass(); 		animal.eatFood(" "); 		AnimalMeat animal2 = new AnimalMeat(); 		animal2.eatFood("  "); 	} 	 }

                 상기 코드 를 통 해 알 수 있 듯 이 이런 수정 비용 은 매우 크다. 새로운 종 류 를 추가 해 야 할 뿐만 아니 라 고객 도 수정 해 야 한다.
         엔 드 코드.일이 있 으 면 차라리 이렇게 수정 하 는 것 이 낫다.

class Animal{ 	public void eatFoodGlass(String animal){ 		System.out.println(animal+"  "); 	}  	public void eatFoodMeat(String animal){ 		System.out.println(animal+"  "); 	} }  public class Client{ 	public static void main(String[] args){ 		Animal animal = new Animal(); 		animal.eatFoodGlass(" "); 		animal.eatFoodGlass(" "); 		animal.eatFoodMeat("  "); 	} } 

             상기 결 과 를 초래 한 것 은 단일 원칙 을 사용 하 는 상황 에서 '직책' 의 구분 에 대해 명확 한 기준 이 없다 는 것 이다. 만약 에
      직책 을 너무 세분 화하 면 오히려 인터페이스 와 실현 류 의 수량 극 을 만 들 고 오히려 유지 와 읽 기 에 불리 하 다.그래서 이 걸 쓰 고 있어 요.
      원칙 은 구체 적 인 문 제 를 구체 적 으로 분석 해 야 한다.
            건 의 는 인터페이스 가 반드시 단일 직책 원칙 을 채택 하고 유형의 디자인 에 있어 가능 한 한 단일 직책 원칙 을 실현 하 는 것 이 가장 좋다 는 것 이다.
      원인 은 한 종류의 변 화 를 일으킨다.