[Spring] 객체지향 설계원칙 (SOLID) - 의존성 역전 원칙 DIP

의존성 역전 원칙 - DIP

 

• 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다."
• 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
• 역할과 구현을 철저하게 분리할 것.

쉽게 예를 들면 현대의 소나타, 아반떼, 싼타페 들은 자동차의 모델명이다.

 

그럼 여기서 자동차는 인터페이스가 될 것이고 소나타, 아반떼, 싼타페 등 모델들은 자동차 라는 인터페이스를 구현한 클래스 라고 볼 수 있다.

 

계속 예제로 사용하였던 서비스센터의 코드를 다시 한번 보자.

 

public class User {

    private final Laptop needRepair;

    public User(Laptop needRepair) {
        this.needRepair = needRepair;
    }

}

// ServiceCenter 인터페이스
public interface ServiceCenter {
    public void repair();
}

// LaptopServicePart 구현 클래스
public class LaptopPart implements ServiceCenter{
    
    @Override
    public void repair() {
        System.out.println("노트북 수리");
    }
}

// SmartphoneServicePart 구현 클래스
public class SmartphonePart implements ServiceCenter{
    
    @Override
    public void repair() {
        System.out.println("스마트폰 수리");
    }
}

 

내가 잘 사용하던 노트북이 고장난 관계로 노트북 수리창구에 방문하였다.

 

엔지니어에게 고장난 노트북을 건네던 도중 스마트폰을 떨어트려 액정이 깨져버렸다.

 

현재 구현된 User 클래스로는 노트북 수리만 가능하게 되어있다.

 

스마트폰을 수리하기 위해선 User 클래스의 코드를 수정해야하는 것이다. 이럴 경우 5원칙 중 하나인 개방-폐쇄 원칙을 위반하게 된다.

 

해서

 

public class User {

    private final ServiceCenter needRepair;

    public User(ServiceCenter needRepair) {
        this.needRepair = needRepair;
    }

}

 

이런 식으로 좀 더 상위개념의 인터페이스인 ServiceCenter 를 의존하게 만들면

 

ServiceCenter 를 구현한 모든 수리 창구를 이용할 수 있게 된다.

---

이로써 객체지향 설계 5원칙 SOLID 의 정리가 마무리 되었다.

 

마지막 의존성 역전 원칙을 정리하던 도중 SOLID 원칙은 각각 별도의 원칙들이 아닌 서로가 연관되어 있는 원칙이라는 생각이 들었다. 의존성 역전 원칙을 잘 지켜 설계하게 되면 개방-폐쇄 원칙도 잘 지키게 되며, 하나의 클래스는 하나의 책임만 가져야 하는 단일 책임 원칙, 그리고 클라이언트의 관심사에 따라 알맞게 인터페이스를 분리해주어야 하는 인터페이스 분리 원칙까지 위반하지 않을 수 있는 것 같다.

 

추후 SOLID 원칙을 더 자세히 잘 알게 된다면 다시 한번 정리할 계획이다.

 

💡 공부 중 정리하는 내용이므로 부족한 부분이 있을 수 있습니다.

 

💡 참고자료

 

스프링 핵심 원리 - 기본편 (인프런 김영한)

스프링 핵심 원리 - 기본편 - 인프런 | 강의