설계 원칙 - 역 치 원칙 에 의존 (DIP)

후진 원칙 에 의존 하 다.
역 치 원칙 에 의존 (Dependence Inversion Principle, DIP)
High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
번역 하면:
1. 고 층 모듈 은 저층 모듈 에 의존 해 서 는 안 되 고 둘 다 추상 에 의존 해 야 한다.
2. 추상 은 세부 사항 에 의존 해 서 는 안 된다.
3. 디 테 일 은 추상 에 의존 해 야 한다.
고 층 모듈: 보통 전략, 업무 장면 만
저층 모듈: 즉 구체 적 으로 실현 되 는 세부 사항 입 니 다.
추상: 추상 이란 인터페이스 나 추상 류 를 말 하 는데 둘 다 직접적 으로 예화 되 어 서 는 안 된다.
디 테 일: 실현 류, 인터페이스 실현 또는 추상 류 계승 으로 인해 발생 하 는 류 는 디 테 일 입 니 다.
 
통속 적 인 점: 의존 역 치 는 추상 (인터페이스 또는 추상 류) 을 통 해 각 종류 나 모듈 의 실현 을 서로 독립 시 키 고 서로 영향 을 주지 않 으 며 모듈 간 의 느슨 한 결합 을 실현 하 는 것 이다.
후진 원칙 에 의존 하여 인 코딩 에서 자주 사용 되 는데 그 핵심 사상 은 인 터 페 이 스 를 대상 으로 프로 그래 밍 하 는 것 이지 프로 그래 밍 을 실현 하 는 것 이 아니다.인 터 페 이 스 는 정의 (규범, 제약) 와 실현 이 분리 되 는 추상 적 인 것 을 말한다. 인터페이스 성명 을 수정 하지 않 으 면 안심 하고 사용 할 수 있 고 인터페이스 내부 의 실현 에 관심 이 없다.그래서 인터페이스 프로 그래 밍 도 프로 토 콜 을 대상 으로 프로 그래 밍 하고 실현 자 는 프로 토 콜 에 따라 일 하 는 것 으로 간단하게 이해 할 수 있다.인터페이스 프로 그래 밍 을 이해 하면 의존 도 를 거꾸로 이해 할 수 있다.
 
문제 설명
클래스 A 는 클래스 B 에 직접 의존 합 니 다. 클래스 A 를 의존 클래스 C 로 바 꾸 려 면 클래스 A 의 코드 를 수정 하여 이 루어 져 야 합 니 다.이런 장면 에서 류 A 는 보통 고 층 모듈 로 복잡 한 업무 논 리 를 책임 진다.클래스 B 와 클래스 C 는 저층 모듈 로 기본 적 인 원자 조작 을 담당 하 며 클래스 A 를 수정 하면 프로그램 에 불필요 한 위험 을 가 져 올 수 있다.
 
해결 방안
클래스 A 를 인터페이스 P 에 의존 하 는 것 으로 수정 하고 클래스 B 와 클래스 C 는 각각 인터페이스 P 를 실현 하 며 클래스 A 는 인터페이스 P 를 통 해 클래스 B 와 클래스 C 와 간접 적 으로 연락 을 하면 클래스 A 를 수정 할 확률 을 크게 낮 출 수 있다.
 
Demo
스승 님 께 서 운전 을 하 십 니 다. 우 리 는 운전 기사 류 가 있 습 니 다. 운전 자 는 현재 벤츠 를 운전 할 수 있 습 니 다. 그래서 우 리 는 성명 류 와 방법 은 다음 과 같 습 니 다.

//   
class Driver {
    func drive(_ benZ: BenZ) {
        benZ.run()
    }
}

//   
class BenZ {
    func run() {
       print("benZ start to run...")
    }
}

코드 가 매우 간단 합 니 다. 기사 가 벤츠 를 운전 하 는 것 은 매우 즐겁게 운전 하 는 것 입 니 다. 그러나 이때 기 사 는 BMW 를 운전 하고 싶 거나 기사 가 아우디 를 운전 하고 싶 어 합 니 다. 어떻게 해 야 합 니까?현재 우리 의 Driver 류 중의 운전 방법 은 BenZ 류 와 밀접 하 게 결합 되 어 있 습 니 다. 기사 가 다른 차 를 운전 하려 고 하 는 것 은 정말 어렵 습 니 다. 비록 우 리 는 Driver 류 에 새로운 방법 을 추가 하여 운전 자 에 게 BMW 를 운전 하 게 할 수 있 지만 이것 은 우호 적 이지 않 습 니 다. 중복 코드 가 너무 많 습 니 다. 분명히 운전 의 기능 입 니 다. 이렇게 많은 방법 을 쓰 는 것 은 분명 옳지 않 습 니 다. 이 문 제 를 해결 하기 위해 서 는....우 리 는 Driver 류 가 벤츠 류 에 대한 의존 을 제거 해 야 한다. 그러면 DIP 원칙 을 사용 해 야 한다.
1. 자동차 협의 성명

//       
protocol CarProtocol {
    func run()
}

2. 벤츠, BMW 모두 자동차 운전 협의 에 따라

//   
class BenZ: CarProtocol {
    func run() {
       print("benZ start to run...")
    }
}

//   
class BMW: CarProtocol {
    func run() {
        print("bmw start to run...")
    }
}

3. 운전 자 는 운전 방법 을 노출 시 키 기만 하면 되 고 협의 에 의존 하여 운전 할 수 있다.

//   
class Driver {
    func drive(_ car: CarProtocol) {
        car.run()
    }
}

 지금 기사 가 운전 하고 싶 은 차 를 운전 하고 있 습 니 다. 아우디 를 운전 하고 싶 으 면 아우디 류 를 만 들 고 자동차 운전 협 의 를 지 키 려 면 OK 입 니 다.

let driver = Driver()
//    
driver.drive(BenZ())
//    
driver.drive(BMW())

만약 에 최적화 하려 면 드라이버 방법 도 인터페이스, 즉 협의 방법 이 라 고 밝 혀 야 한다. 그러나 개인 적 으로 현재 OK 라 고 느낀다. 우리 가 말 한 고 층 모듈 은 저층 모듈 에 의존 해 서 는 안 되 고 둘 다 추상 에 의존 해 야 한다.추상 은 세부 사항 에 의존 해 서 는 안 된다.세부 사항 은 추상 에 의존 해 야 한다.
 
후진 원칙 의 장점 에 의존 하 다.
1. 클래스 간 의 결합 성 감소
2. 시스템 안정성 향상
3. 병행 개발 로 인 한 위험 감소
4. 코드 의 가 독성 과 유지 가능성 향상
 
의존 주입
의존 은 전 달 될 수 있 고 A 대상 은 B 대상 에 의존 하고 B 대상 은 C 대상 에 의존 하 며 C 대상 은 D 에 의존한다.끊임없이 의존 하지만 한 가 지 를 기억 하 라. 추상 적 인 의존 만 하면 다 층 적 인 의존 전달 도 상관없다.
주입 에 의존 하 는 방식, 더 자세 한 내용 은 여 기 를 보 세 요.
1. 구조 함수 주입

class Driver {
    let car: CarProtocol

    init(_ car: CarProtocol) {
        self.car = car
    }

    func drive() {
        car.run()
    }
}

2, 속성 주입

class Driver {
    var car: CarProtocol?
    func drive() {
        car?.run()
    }
}

3. 방법 주입

class Driver {
    func drive(_ car: CarProtocol) {
        car.run()
    }
}

 
 
레 퍼 런 스
디자인 모델 6 대 원칙 을 신속히 이해 하 다.
디자인 모델 6 대 원칙 (3): 후진 원칙 에 의존