C \ # 디자인 모델 (28 가지) - 원칙 3: 단일 직책 원칙

단일 직책 원칙 은 너무 간단 하기 때문에 경험 이 있 는 프로그래머 는 디자인 모델 을 읽 어 본 적 이 없고 단일 직책 원칙 을 들 어 본 적 이 없 더 라 도 소프트웨어 를 디자인 할 때 이 중요 한 원칙 을 자각 적 으로 지 키 는 것 이 상식 이기 때문이다.소프트웨어 프로 그래 밍 에서 누구 도 하나의 기능 을 수정 했다 고 해서 다른 기능 이 고장 나 는 것 을 원 하지 않 는 다.이 문 제 를 피 하 는 방법 은 단일 직책 원칙 을 따 르 는 것 이다.단일 직책 원칙 이 이렇게 간단 하고 상식 적 으로 여 겨 지지 만 경험 이 풍부 한 프로그래머 가 쓴 프로그램 이라도 이 원칙 에 어 긋 나 는 코드 가 존재 한다.왜 이런 현상 이 나 타 났 을 까?확산 할 직책 이 있 기 때문이다.직책 확산 이란 어떤 이유 로 직책 이 더 가 는 직책 으로 분 화 된 것 이다.
예 1: 동물 이 호흡 하 는 장면 을 한 가지 유형 으로 묘사 하 다.
class Animal {

public void breathe(string animal)
{
    Debug.Log(animal + "    ");
}

}
public class Client { Animal animal = new Animal();

void Start()
{

    animal.breathe(" ");
    animal.breathe(" ");
    animal.breathe(" ");
}

}
운행 결과: / / 소 호흡 공기 / / 양 호흡 공기 / 돼지 호흡 공기
수요 변동 * * 프로그램 이 출시 된 후에 문 제 를 발 견 했 습 니 다. 모든 동물 이 공 기 를 마 시 는 것 이 아 닙 니 다. 예 를 들 어 물고 기 는 물 을 마 시 는 것 입 니 다.수정 시 단일 직책 원칙 에 따라 동물 류 를 육 생동 물 류 Terrestrial, 수생동물 Aquatic 로 세분 화해 야 합 니 다. * * 코드 는 다음 과 같 습 니 다.
class Terrestrial {public void breathe (String animal) {Debug. Log (animal + "호흡 공기");}}
class Aquatic {public void breathe (String animal) {Debug. Log (animal + "호흡 수");}}
public class Client {public static void main (String [] args) {Terrestrial terrestrial = new Terrestrial (); terestrial. breathe ("소"); terestrial. breathe ("양"); terestrial. breathe ("돼지");

    Aquatic aquatic = new Aquatic();
    aquatic.breathe(" ");
}

}
/: 운행 결과: / 소 호흡 공기 / / 양 호흡 공기 / 돼지 호흡 공기 / / 물고기 호흡 물
변 동량 이 적은 방법: 만약 에 이렇게 비용 을 수정 하 는 것 이 매우 크다 면 원래 의 종 류 를 분해 하 는 것 외 에 클 라 이언 트 를 수정 해 야 한 다 는 것 을 알 게 될 것 입 니 다. 그리고 동물 을 직접 수정 하여 목적 을 달성 하 는 것 은 단일 직책 원칙 에 위배 되 지만 비용 은 적 습 니 다. 코드 는 다음 과 같 습 니 다.
class Animal {public void breathe (String animal) {if ("물고기" = = animal) {Debug. Log ((animal + "호흡 수");} else {Debug. Log (animal + "호흡 기");}}}}}
public class Client {public static void main (String [] args) {동물 = new Animal (); animal. breathe ("소"); animal. breathe ("양"); animal. breathe ("돼지"); animal. breathe ("물고기");}}}
위험 을 볼 수 있 습 니 다. 이런 수정 방식 은 훨씬 간단 해 야 합 니 다. 그러나 위험 이 존재 합 니 다. 어느 날 물고 기 를 민물 을 호흡 하 는 물고기 와 바닷물 을 호흡 하 는 물고기 로 나 누 어야 하고, Animal 류 의 breathe 방법 을 수정 해 야 합 니 다. 기 존 코드 에 대한 수정 은 '돼지', '소', '양' 을 호출 합 니 다.관련 기능 이 위험 을 가 져 오 면 어느 날 프로그램 이 실 행 된 결과 가 '우 후 흡수' 로 바 뀌 었 다 는 것 을 알 게 될 것 이다. 이런 수정 방식 은 코드 등급 에서 단일 직책 원칙 에 위배 된다. 수정 이 가장 간단 하지만 위험 이 가장 크다.
다른 수정 방식
class Animal {public void breathe (String animal) {Debug. Log (animal + "숨 쉬 기");}

public void breathe2(String animal)
{
    Debug.Log(animal + "   ");
}

}
public class Client {public static void main (String [] args) {동물 = new Animal (); animal. breathe ("소"); animal. breathe ("양"); animal. breathe ("돼지"); animal. breathe 2 ("물고기");}}}이 를 통 해 알 수 있 듯 이 이러한 수정 방식 은 원래 의 방법 을 바 꾸 지 않 고 유형 에 하나의 방법 을 추가 했다. 이렇게 하면 단일 직책 원칙 에 위배 되 지만 방법 등급 에 있어 서 는 단일 직책 원칙 에 부합된다. 왜냐하면 그것 은 원래 의 방법의 코드 를 움 직 이지 않 았 기 때문이다. 이 세 가지 방식 은 각각 장단 점 이 있다. 그러면 실제 프로 그래 밍 에서 어떤 것 을 사용 할 것 인가?실제 상황 에 따라 확정 해 야 합 니 다. 제 원칙 은 논리 가 충분 하고 간단 해 야 코드 등급 에서 단일 직책 원칙 을 위반 할 수 있 고 유형 중의 방법 수량 이 충분 해 야 방법 등급 에서 단일 직책 원칙 을 위반 할 수 있 습 니 다.
단일 직책 원 의 장점 에 따라 유형의 복잡 도 를 낮 출 수 있 고 한 가지 직책 만 맡 을 수 있 으 며 그 논 리 는 여러 가지 직책 을 맡 는 것 보다 간단 할 것 이다. 유형의 가 독성 을 향상 시 키 고 시스템 의 유지 가능성 을 향상 시 킬 수 있다. 변경 으로 인 한 위험 이 낮 아 지고 변경 은 필연 적 인 것 이다. 만약 에 단일 직책 원칙 이 잘 지 켜 지면 하나의 기능 을 수정 할 때 그 에 대한 위험 을 현저히 낮 출 수 있다.그의 기능 의 영향. 설명 해 야 할 것 은 단일 직책 원칙 은 대상 을 대상 으로 프로 그래 밍 사상 이 특유 한 것 이 아니 라 모듈 화 된 프로 그래 밍 이 라면 모두 단일 직책 원칙 을 적용 한 다 는 것 이다.