DIP

SOLID 中 DIP

DIP(Dependency Inversion Principle) 즉, 의존관계 역전 원칙이란,

"추상화에 의존해야지, 구체화에 의존하면 안 된다." 는 원칙이다.

• 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

• 대신 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.

고수준 모듈 : 어떤 의미 있는 단일 기능을 제공하는 모듈(interface, 추상 클래스)

저수준 모듈 : 고수준 모듈의 기능을 구현하기 위해 필요한 하위 실제 구현(메인 클래스, 객체) DIP : High-level modules should not depend on low-level modules. Both should depend on abstractions. (고수준 모듈은 저수준 모듈에 의존해서는 안된다. 둘다 추상화에 의존해야 합니다.) AND Abstractions should not depend on details. Details should depend on abstractions. (추상화는 세부 사항에 의존해서는 안된다. 세부사항은 추상화에 따라 달라집니다.)

쉽게 설명하면, 클라이언트의 요청을 받는 컨트롤러(Cotroller)가 있고 비즈니스 로직을 처리하는 서비스(Service)가 있다. 컨트롤러(고수준)는 서비스(저수준)를 직접적으로 의존하지 않고 추상화 된 인터페이스에 의존해야 한다는 것이다.

이러한 설명으로만 봤을 때 이해하기 힘들었기 때문에, 왜 사용하고 어떻게 사용하는지에 대해서 알아봐야 한다.

계층 구조 아키텍처

보통 계층 구조는 위 사진과 같은 구조로 되어있다.

• 표현 계층 : 사용자의 요청을 받아 응용 영역에 전달함과 동시에 처리 결과를 사용자에게 표시

• 응용 계층 : 사용자에게 제공할 기능 구현

• 도메인 계층 : 도메인의 핵심 로직과 모델을 구현

• 인프라 계층 : DB 연동과 같은 구현 기술을 다룬다.

각 계층은 서로 다른 특징을 가지고 있으며 상위 계층은 하위 계층에게 의존하지만, 하위 계층은 상위 계층에 의존하지 않는다. 하지만 그렇게 되면 인프라 계층에 종속적인 현상이 많이 발생하게 된다.

---

예시

택배 회사를 선택하는 서비스가 있습니다. 사용자는 자신이 원하는 택배 회사를 선택할 수 있습니다.

/*
 * 롯데 택배 : 저수준 모듈
 */
public class CompanyOfLotte {
    public String speed() {
        return "fast";
    }
}

/*
 * 배달 서비스 : 고수준 모듈
 */
public class SelectCompanyService {

    private CompanyOfLotte lotte;

    public String speed() {
        return lotte.speed();
    }
}

해당 코드에는 문제점이 존재합니다.

1. 단위 테스트가 어렵다.

위 코드는 Service만 온전히 테스트 할 수 없다. 인프라 계층에 속하는 Lotte가 완벽하게 동작해야 Service를 테스트할 수 있다.

1. 확장과 변경이 어렵다.

만약 새로운 회사인 한진(Hanjin)이 추가된다면 어떻게 될까? 회사가 추가될 때마다 기존 Service에 새로운 회사를 추가해야한다.

/*
 * 한진 택배 : 저수준 모듈
 */
public class CompanyOfHanjin {
    public String speed() {
        return "little slow";
    }
}


/*
 * 회사 선택 서비스 : 고수준 모듈
 */
public class SelectCompanyService {

    private CompanyOfLotte lotte;
    private CompanyOfHanjin hanjin

    public String speed(String company) {
        if (company.eqauls("lotte") return lotte.speed();
        else return hanjin.speed();
    }
}

이렇게 인프라 계층이 확장 될 때마다 서비스 코드를 수정하는 것은 좋지 않은 코드라고 얘기한다.

예시에서는 서비스가 고수준 모듈이고, 회사들이 저수준 모듈이다. 그렇기 때문에 의존 방향은 서비스에서 회사로 향한다. 즉, 고수준 모듈이 저수준 모듈을 의존하고 있다.

DIP를 적용해보자.

DIP를 적용 하게되면 저수준 모듈이 고수준 모듈에 의존 하게 의존 방향이 역전이 된다.

• 그러기 위해서는 위에서도 얘기한 추상 타입(인터페이스, 추상 클래스)가 필요하다.

public interface Company {
    String speed();
}

우선 저수준 모듈이 상속받을 인터페이스를 만든다.

/*
 * 롯데 택배 : 저수준 모듈
 */
public class CompanyOfLotte implements Company {
    
    @Override
    public String speed() {
        return "fast";
    }
}

/*
 * 한진 택배 : 저수준 모듈
 */
public class CompanyOfHanjin implements Company {
    
    @Override
    public String speed() {
        return "little slow";
    }
}

저수준 모듈들은 인터페이스의 구현체가 된다.

/*
 * 회사 선택 서비스 : 고수준 모듈
 */
public class SelectCompanyService {

    private Company company;
    
    public SelectCompanyService(Company cp) {
        company = cp;
    }

    public String speed() {
        return company.speed();
    }
}

이제 Service는 Company 인터페이스를 의존하고 새로운 Company가 추가된다 하더라도 Service 로직은 변경할 필요가 없다.

이렇게 변경 하더라도 Runtime flow는 변함이 없다.

클래스 다이어그램

즉, 저수준 모듈이 고수준 모듈에 의존하게 되는 것을 DIP라고 한다.