[소프트웨어] dip (비공개)

SOLID 원칙 중 의존성 역전 원칙에 대해서 들어봤을 것이다.

 

그래서 뭐 어쩌라는 건가?

뭐가 나쁜 예시고, 뭐가 좋은 예시라는 건가?

그것에 대한 생각은 아래에 있다.

 

우선,

의존성 역전 원칙을 지켜라라는 말은 아래와 같다.

객체는 저수준 모듈보다 고수준 모듈에 의존해야한다는 원칙이다.

 

* 고수준 모듈 : 인터페이스와 같은 객체의 형태나 추상적 개념

* 저수준 모듈 : 구현된 객체

 

 

 

아래에 예시가 있다.

우선, 간단하게 스토리를 짜본다.

- 컵을 생성하는 공정은 여러개가 될 수 있다. (컵공정A, 컵공정B)

- 컵공정에 들어가는 통제정책은 여러개 될 수가 있다. (컵공정_권한통제정책A, 컵공정_권한통제정책)

- 이때, 컵공정_권한통재정책은 컵공정을 객체로 가지게 되된다.

 

즉, 나쁜 예시는 아래이고,

아래 예시의 단점은, 컵공정_권한통제정책A가 오로지 컵공정A()의 생성을 받고 있다는 것.

class 컵공정_권한통제정책A implements 컵공정 {
    컵공정 = new 컵공정A();
    ...
}

 

좋은 예시는 아래이다.

하지만, 아래처럼, 인터페이스를 인자로 받아 사용하면,

여러 컵공정에 대해서, 권한통제A를 이용할 수 잇게 된다.

class 컵공정_권한통제A implements 컵공정 {
  컵공정 process;
  
  public 컵공정_권한통제A(컵공정 process) {
      this.process = process;
  }
}

 

이 SOLID 원칙을 만든 사람이 하고 싶은 말은,

너가 다른 모듈/레이어의 객체를 생성해서 쓸 때, 

그것이 인터페이스로 정의된 인자로 받아서 쓸 수 있는 지를 먼저 검토하고, 그걸 써라라는 의미이다.

 

의존성 역전 원칙에 대한 개념/정의는 누구나 다 알 것이다.

하지만, 그 원칙을 지켰냐 못지켰냐에 대한 설명은 잘 없는 것 같아서 정리해보았다.