6 대 원칙 중 하나: 단일 직책 원칙

단일 직책 원칙
정의: 클래스 변경 을 초래 하 는 원인 보다 많 지 않 습 니 다.한 가지 직책 만 맡 는 다 는 것 이 통속 적 이다.문제 의 유래: 유형 T 는 두 가지 서로 다른 직책 을 책임 진다. 직책 P1, 직책 P2.직책 P1 수요 가 바 뀌 어 클래스 T 를 수정 해 야 할 경우 정상적으로 작 동 하 던 직책 P2 기능 이 고장 날 수 있 습 니 다.해결 방안: 단일 직책 원칙 에 따른다.각각 두 가지 유형의 T1, T2 를 구축 하여 T1 이 직책 P1 기능 을 완성 하고 T2 는 직책 P2 기능 을 완성 하도록 한다.이렇게 하면 류 T1 을 수정 할 때 직책 P2 에 고장 위험 이 발생 하지 않 습 니 다.마찬가지 로 T2 를 수정 할 때 도 직책 P1 에 고장 위험 이 발생 하지 않 는 다.
단일 직책 원칙 에 대해 말하자면 많은 사람들 이 거들 떠 보지 도 않 을 것 이다.너무 쉬 우 니까.경험 이 있 는 프로그래머 는 디자인 모델 을 읽 어 본 적 이 없고 단일 직책 원칙 을 들 어 본 적 이 없 더 라 도 소프트웨어 를 디자인 할 때 이 중요 한 원칙 을 자각 적 으로 지 키 는 것 이 상식 이기 때문이다.소프트웨어 프로 그래 밍 에서 누구 도 하나의 기능 을 수정 했다 고 해서 다른 기능 이 고장 나 는 것 을 원 하지 않 는 다.이 문 제 를 피 하 는 방법 은 단일 직책 원칙 을 따 르 는 것 이다.단일 직책 원칙 이 이렇게 간단 하고 상식 적 으로 여 겨 지지 만 경험 이 풍부 한 프로그래머 가 쓴 프로그램 이라도 이 원칙 에 어 긋 나 는 코드 가 존재 한다.왜 이런 현상 이 나 타 났 을 까?확산 할 직책 이 있 기 때문이다.직책 확산 이란 어떤 이유 로 직책 P 가 입도 가 더 가 는 직책 P1 과 P2 로 분 화 된 것 이다.예 를 들 어 류 T 는 하나의 직책 P 만 책임 지고 이런 디자인 은 단일 직책 원칙 에 부합된다.나중에 어떤 이유 로 수요 가 변경 되 었 을 수도 있 고 프로그램의 설계 자의 경계 가 높 아 졌 을 수도 있 습 니 다. 직책 P 를 입도 가 더 가 는 직책 P1, P2 로 세분 화 해 야 합 니 다. 이때 절차 가 단일 직책 원칙 을 따 르 려 면 유형 T 도 두 가지 유형 T1 과 T2 로 나 누 어 P1, P2 두 가지 직책 을 각각 책임 져 야 합 니 다.그러나 프로그램 이 이미 다 쓴 상황 에서 이렇게 하 는 것 은 정말 시간 이 너무 걸린다.따라서 간단 한 수정 류 T 는 이 를 통 해 두 가지 직책 을 맡 는 것 이 좋 은 선택 이다. 비록 이렇게 하 는 것 은 단일 직책 원칙 에 위배 되 지만.(이렇게 하 는 위험 은 직책 확산 의 불확실 성에 있다. 왜냐하면 우 리 는 이 직책 P 가 미래 에 P1, P2, P3, P4 로 확 산 될 것 이 라 고 생각 하지 못 하기 때문이다. 그러므로 직책 이 우리 가 통제 할 수 없 을 정도 로 확산 되 기 전에 코드 를 즉시 재 구성 하 는 것 을 기억 하 라.)
예 를 들 어 동물 이 호흡 하 는 장면 을 한 가지 유형 으로 묘사 했다.

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

실행 결과:
소 는 공 기 를 마시고 양 은 공 기 를 마시고 돼지 는 공 기 를 마신다.
프로그램 이 출시 된 후에 문 제 를 발견 했다. 모든 동물 이 공 기 를 마 시 는 것 이 아니다. 예 를 들 어 물고 기 는 물 을 마 시 는 것 이다.
첫 번 째 수정 은 단일 직책 원칙 에 따라 수정 할 때 단일 직책 원칙 에 따라 동물 류 를 육 생동 물 류 Terrestrial, 수생동물 Aquatic 로 세분 화해 야 한다.
코드 는 다음 과 같 습 니 다:

class Terrestrial{  
    public void breathe(String animal){  
        System.out.println(animal+"    ");  
    }  
}  
class Aquatic{  
    public void breathe(String animal){  
        System.out.println(animal+"   ");  
    }  
}  

public class Client{  
    public static void main(String[] args){  
        Terrestrial terrestrial = new Terrestrial();  
        terrestrial.breathe(" ");  
        terrestrial.breathe(" ");  
        terrestrial.breathe(" ");  

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

실행 결과:
소 호흡 공기 양 호흡 공기 돼지 호흡 공기 물고기 호흡 수
이렇게 수정 하면 비용 이 많이 들 고 새로운 종 류 를 추가 하 는 것 외 에 클 라 이언 트 도 수정 해 야 한 다 는 것 을 알 게 될 것 입 니 다.한편, 동물 을 직접 수정 하여 목적 을 달성 하 는 것 은 단일 직책 원칙 에 어 긋 나 지만 비용 은 적다.
두 번 째 수정 은 단일 방법의 직책 원칙 을 위반 하 는 코드 는 다음 과 같다.

class Animal{  
    public void breathe(String animal){  
        if(" ".equals(animal)){  
            System.out.println(animal+"   ");  
        }else{  
            System.out.println(animal+"    ");  
        }  
    }  
}  

public class Client{  
    public static void main(String[] args){  
        Animal animal = new Animal();  
        animal.breathe(" ");  
        animal.breathe(" ");  
        animal.breathe(" ");  
        animal.breathe(" ");  
    }  
}  

이런 수정 방식 은 훨씬 간단 해 야 한 다 는 것 을 알 수 있다.그러나 위험 이 존재 한다. 어느 날 물고 기 를 민물 을 호흡 하 는 물고기 와 바닷물 을 호흡 하 는 물고기 로 나 누 어야 하고, 동물 류 의 breathe 방법 을 수정 해 야 한다. 기 존 코드 에 대한 수정 은 '돼지', '소', '양' 등 관련 기능 을 호출 하 는 데 위험 을 가 져 올 수 있다. 아마도 어느 날 프로그램 이 실 행 된 결과 가 '소 호 흡수' 로 바 뀌 었 다 는 것 을 알 게 될 것 이다.이런 수정 방식 은 코드 등급 에서 단일 직책 원칙 에 직접적 으로 위배 되 고 수정 이 가장 간단 하지만 위험 이 가장 크다.세 번 째 수정, 방법 등급 은 단일 직책 원칙 에 부합 되 고 다음 과 같은 수정 방식 이 있다.

class Animal{  
    public void breathe(String animal){  
        System.out.println(animal+"    ");  
    }  

    public void breathe2(String animal){  
        System.out.println(animal+"   ");  
    }  
}  

public class Client{  
    public static void main(String[] args){  
        Animal animal = new Animal();  
        animal.breathe(" ");  
        animal.breathe(" ");  
        animal.breathe(" ");  
        animal.breathe2(" ");  
    }  
}  

이 를 통 해 알 수 있 듯 이 이런 수정 방식 은 원래 의 방법 을 바 꾸 지 않 고 유형 에 하나의 방법 을 추가 했다. 이렇게 하면 단일 직책 원칙 에 위배 되 지만 방법 등급 에 있어 서 단일 직책 원칙 에 부합 되 는 것 이다. 왜냐하면 원래 의 방법 코드 를 움 직 이지 않 았 기 때문이다.
이 세 가지 방식 은 각각 장단 점 이 있 는데, 그렇다면 실제 프로 그래 밍 에서 어느 것 을 사용 합 니까?
사실 이것 은 정말 말 하기 어렵 기 때문에 실제 상황 에 따라 확정 해 야 한다.나의 원칙 은 논리 가 충분 하고 간단 해야만 방법 등급 에서 단일 직책 원칙 을 위반 할 수 있다 는 것 이다.클래스 중의 방법 수량 이 충분 하지 않 아야 클래스 중의 코드 등급 에서 단일 직책 원칙 을 위반 할 수 있다.
예 를 들 어 본 고 에서 제시 한 이 예 는 너무 간단 하고 한 가지 방법 만 있 기 때문에 코드 등급 에서 단일 한 직책 원칙 을 위반 하 든 방법 등급 에서 위반 하 든 큰 영향 을 주지 않 을 것 이다.실제 응용 중의 유형 은 모두 복잡 해 야 한다. 직책 이 확산 되 고 유형 을 수정 해 야 할 때 이런 유형 자체 가 매우 간단 하지 않 으 면 단일 직책 원칙 을 지 키 는 것 이 좋다.
단일 직책 에 따 른 장점 은 다음 과 같다.
4. 567917. 유형의 복잡 도 를 낮 출 수 있 고 한 가지 직책 만 맡 을 수 있 으 며 그 논 리 는 여러 가지 직책 을 맡 는 것 보다 훨씬 간단 할 것 이다
4. 567917. 유형의 가 독성 을 향상 시 키 고 시스템 의 유지 가능성 을 향상 시킨다
4. 567917. 변경 으로 인 한 위험 이 낮 아 지고 변경 은 필연 적 인 것 이다. 만약 에 단일 직책 원칙 이 잘 지 키 면 하나의 기능 을 수정 할 때 다른 기능 에 대한 영향 을 현저히 낮 출 수 있다.설명 해 야 할 것 은 단일 직책 원칙 은 대상 을 대상 으로 프로 그래 밍 사상 이 특유 한 것 이 아니 라 모듈 화 된 프로 그래 밍 이 라면 모두 단일 직책 원칙 을 적용 한 다 는 것 이다
원래 주소:http://blog.csdn.net/zhengzhb/article/details/7278174