디자인 모델 6 대 원칙 (3): 후진 원칙 에 의존

후진 원칙 에 의존:
A. 고 차원 의 모듈 은 저 차원 의 모듈 에 의존 해 서 는 안 되 고 그들 은 모두 추상 에 의존 해 야 한다.
B. 추상 은 구체 에 의존 하지 말고 구체 적 으로 추상 에 의존 해 야 한다.
정의: 고 층 모듈 은 저층 모듈 에 의존 해 서 는 안 되 고 둘 다 추상 에 의존 해 야 한다.추상 은 세부 사항 에 의존 해 서 는 안 된다.세부 사항 은 추상 에 의존 해 야 한다.
문제 의 유래: 클래스 A 는 클래스 B 에 직접 의존 합 니 다. 클래스 A 를 의존 클래스 C 로 바 꾸 려 면 클래스 A 의 코드 를 수정 하여 이 루어 져 야 합 니 다.이런 장면 에서 류 A 는 보통 고 층 모듈 로 복잡 한 업무 논 리 를 책임 진다.클래스 B 와 클래스 C 는 저층 모듈 로 기본 적 인 원자 조작 을 책임 집 니 다.클래스 A 를 수정 하면 프로그램 에 불필요 한 위험 을 가 져 올 수 있 습 니 다.
해결 방안: 클래스 A 를 인터페이스 I 에 의존 하 는 것 으로 수정 하고 클래스 B 와 클래스 C 는 각각 인터페이스 I 를 실현 하 며 클래스 A 는 인터페이스 I 를 통 해 클래스 B 또는 클래스 C 와 간접 적 으로 연락 하면 클래스 A 를 수정 할 확률 을 크게 낮 출 수 있다.
       후진 원칙 에 의존 하 는 것 은 이러한 사실 을 바탕 으로 한다. 세부 적 인 다 변성 에 비해 추상 적 인 것 이 안정 적 이 어야 한다.추상 을 바탕 으로 구 축 된 구 조 는 디 테 일 을 바탕 으로 구 축 된 구조 보다 훨씬 안정 적 이다.자바 에서 추상 은 인터페이스 나 추상 류 를 말 하 는데 세부 적 인 것 은 구체 적 인 실현 류 이다. 인터페이스 나 추상 류 를 사용 하 는 목적 은 규범 과 계약 을 잘 제정 하고 구체 적 인 조작 과 관련 되 지 않 으 며 세부 적 인 임 무 를 그들의 실현 류 에 맡 기 는 것 이다.
       후진 원칙 에 의존 하 는 핵심 사상 은 인 터 페 이 스 를 대상 으로 프로 그래 밍 하 는 것 이다. 우 리 는 인터페이스 프로 그래 밍 이 실현 을 위 한 프로 그래 밍 보다 어디 가 좋 은 지 예 를 들 어 설명 한다.장면 은 이 렇 습 니 다. 어머니 가 아이 에 게 이 야 기 를 해 주 고 책 한 권 만 주면 아이 에 게 이 야 기 를 해 줄 수 있 습 니 다.코드 는 다음 과 같 습 니 다:

class Book{
    public String getContent(){
        return "               ……";
    }
}
 
class Mother{
    public void narrate(Book book){
        System.out.println("       ");
        System.out.println(book.getContent());
    }
}
 
public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
    }
}

실행 결과:
엄마 가 이 야 기 를 하기 시 작 했 어 요. 아주 오래 전에 아랍 이야기 가 있 었 는데...
       잘 돌아 가 고 있 습 니 다. 만약 에 어느 날 수요 가 이렇게 된다 면 책 을 주 는 것 이 아니 라 신문 을 주 는 것 입 니 다. 이 어머니 에 게 신문 의 이 야 기 를 들 려 드 리 겠 습 니 다. 신문 의 코드 는 다음 과 같 습 니 다.

class Newspaper{
    public String getContent(){
        return "   38+7         ……";
    }
}

 이 어머니는 신문 에 실 린 이 야 기 를 읽 을 줄 모 르 니 황당 하 다. 책 을 신문 으로 바 꿨 을 뿐 어머니 를 고 쳐 야 읽 을 수 있다 니.나중에 잡지 로 바 꿔 야 한다 면?홈 페이지 로 바 꿀 까요?Mother 를 계속 수정 해 야 한 다 는 것 은 분명 좋 은 디자인 이 아니다.그 이 유 는 Mother 와 Book 간 의 결합 성 이 너무 높 아서 그들 간 의 결합 도 를 낮 춰 야 하기 때문이다.
우 리 는 추상 적 인 인터페이스 IReader 를 도입 했다.도 서 는 글자 가 있 는 것 이 라면 모두 도서 에 속한다.

interface IReader{
    public String getContent();
}

Mother 류 와 인터페이스 IReader 는 의존 관계 가 발생 하고 Book 과 Newspaper 는 모두 도서 의 범주 에 속 합 니 다. 그들 은 각자 IReader 인 터 페 이 스 를 실현 합 니 다. 그러면 의존 후진 원칙 에 부합 되 고 코드 는 다음 과 같이 수정 되 었 습 니 다.

class Newspaper implements IReader {
    public String getContent(){
        return "   17+9        ……";
    }
}
class Book implements IReader{
    public String getContent(){
        return "               ……";
    }
}
 
class Mother{
    public void narrate(IReader reader){
        System.out.println("       ");
        System.out.println(reader.getContent());
    }
}
 
public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

실행 결과:
엄마 가 이 야 기 를 하기 시작 했다.      옛날 에 아랍 이야기 가 있 었 는데...      엄마 가 이 야 기 를 하기 시작 했다.      임 서호 17 + 9 조 닉 스 독수리 처치...
 이렇게 수정 하면 앞으로 클 라 이언 트 클래스 를 어떻게 확장 하 든 Mother 클래스 를 수정 할 필요 가 없습니다.이것 은 간단 한 예 일 뿐 실제 상황 에서 고 층 모듈 을 대표 하 는 Mother 류 는 주요 업무 논 리 를 완성 하 는 것 을 책임 지고 이 를 수정 해 야 한다 면 잘못된 위험 을 도입 할 것 이다.따라서 의존 후진 원칙 에 따라 클래스 간 의 결합 성 을 낮 추고 시스템 의 안정성 을 향상 시 키 며 수정 절차 로 인 한 위험 을 낮 출 수 있다.
 후진 원칙 에 의존 하 는 것 은 여러 사람 이 병행 개발 하 는 데 큰 편 의 를 가 져 왔 다. 예 를 들 어 상기 사례 에서 원래 Mother 류 와 Book 류 가 직접 결합 할 때 Mother 류 는 Book 류 인 코딩 이 완 성 된 후에 야 인 코딩 을 할 수 있다. 왜냐하면 Mother 류 는 Book 류 에 의존 하기 때문이다.수 정 된 절 차 는 동시에 착공 할 수 있 고 서로 영향 을 주지 않 는 다. 왜냐하면 Mother 는 Book 류 와 아무런 관계 가 없 기 때문이다.협력 개발 에 참여 하 는 사람 이 많 을 수록 프로젝트 가 커지 고 의존 으로 인 한 원칙 을 채택 하 는 의미 가 크다.현재 유행 하 는 TDD 개발 모델 은 후진 원칙 에 의존 하 는 가장 성공 적 인 응용 이다.
  전달 의존 관 계 는 세 가지 방식 이 있 는데 이상 의 예 에서 사용 하 는 방법 은 인터페이스 전달 이다. 또한 두 가지 전달 방식 도 있다. 구조 방법 전달 과 setter 방법 전달 은 Spring 프레임 워 크 를 사용 한 적 이 있 기 때문에 의존 하 는 전달 방식 이 낯 설 지 않 을 것 이 라 고 믿는다.실제 프로 그래 밍 에서 우 리 는 보통 다음 과 같은 세 가 지 를 해 야 한다.
저층 모듈 은 가능 한 한 추상 류 나 인터페이스 가 있어 야 하거나 둘 다 있어 야 한다
변수의 성명 형식 은 가능 한 한 추상 적 인 클래스 나 인터페이스 입 니 다
계승 을 사용 할 때 리 씨 교체 원칙 을 따른다
후진 원칙 에 의존 하 는 핵심 은 바로 우리 가 인 터 페 이 스 를 대상 으로 프로 그래 밍 을 하 라 는 것 이다. 인터페이스 프로 그래 밍 을 이해 하면 후진 에 의존 하 는 것 을 이해 할 수 있다.
 디자인 모델 6 대 디자인 원칙 내 비게 이 션:
1.  단일 직책 원칙 (Single Responsibility Principle）
2.  리 씨 교체 원칙 (Liskov) Substitution Principle）
3.  후진 원칙 에 의존 Inversion Principle）
4.  인터페이스 격 리 원칙 (인터페이스 Segregation Principle）
5.  디 미트 법칙 Of Demeter）
6. 개폐 원칙 (Open - Close) Principle)