Factory Method Pattern ③ DIP (Dependency Inversion Principle)

패턴 책을 보면서 중간 즈음에 나오는 Dependency Inversion Principle (이하, DIP) 라는 원칙이 나옵니다. 한국말로 해석을 하자면 의존성 뒤집기 원칙이라고 하는데, 의존성이라는 것에 대해서 다시 한번 생각해본다면 무언가에 의존한다는 건 마치 서브 클래스들이 상위 클래스에 의존한다는 것과 뉘앙스가 비슷하다는 생각이 듭니다.

근데 의존성 뒤집기라고 부르는 이유가 뭘까요??? 디자인 원칙으로 이렇게 이야기 합니다.

추상화된 것에 의존하도록 만들어라. 구상 클래스에 의존하도록 만들지 않도록 한다.

역시 뭔말인지 못알아 듣겠습니다. 확실한건 추상화를 사용하라는걸 보니 추상클래스나 인터페이스 중심으로 설계를 하라는 것 처럼 보입니다. 이전에 이야기 했던 특정 구현이 아닌 인터페이스에 맞춰서 프로그래밍 하라는 말과 비슷한건가 생각해봅니다만.. 그저 비슷할 뿐이라네요. 뭔소린지 좀더 알아보도록 하겠습니다 ㅎㅎㅎ

'추상화' 라는 것에 대해서 강조한 것이 틀리다고 합니다. 아.. 뭔가 와닿지 않으니 그림을 그려가면서 배워보도록 할래요 -ㅅ-;;

이런 클래스 다이어그램을 그렸었죠? 여기서 UnitMaker 라던가 Factory 클래스들이 없다고 생각을 한다면, ProtossUnit 클래스에서 객체 생성에 관여를 해야 하겠지용 많은 조건문들을 사용하여 질럿을 생산할지 드라군을 만들지.. 결정을 해야겠죠. 이런경우가 심하게 의존적인 경우라고 보시면 되겠습니다. 다른 유닛들이 더 있으니.. ProtossUnit 이라는 클래스는 어마어마한 책임을 가지고 있는 클래스가 되겠습니다.

위와 같이 다이어그램을 그대로 보면, ProtossUnit 이라는 추상클래스에 대해서 여러 유닛들이 의존적입니다. 이건 서브클래스이니까 당연한 경우입니다. 한마디로 저수준의 구성요소들이 고수준의 구성요소에 의존적인 경우입니다. 그런데 고수준 구성요소인 UnitMaker라는 클래스 역시 ProtossUnit 에 의존적입니다. 고수준과 저수준이 둘 다 하나의 추상 클래스에 의존하게 되는 겁니다.

간단하게 이야기를 해보도록 할게요. 디자인을 함에 있어서, UnitMaker를 구현해야하면 이하 구상 클래스들을 만들어가면 되던가요?? 그렇게 되면 심하게 구상 클래스에만 의존적인 문제가 생깁니다. UnitMaker 클래스는 책임이 많아지게 되구요.
여기서 Inversion의 의미가 나옵니다. 생각하는 순서를 뒤집어 보라는 겁니다. 고수준의 클래스부터 생각하는것 대신에 ProtossUnit 클래스에대해서 먼저 생각해보고 추상화시킬 수 있는것이 무엇인지 생각하는 겁니다. 일단 팩토리를 사용하여 UnitMaker의 구상 클래스들을 없애고, 팩토리를 사용하게되면 다양한 구상 유닛 형식이 추상화된 ProtossUnit에 의존하게 될테고, 마찬가지로 UnitMaker도 추상화된 ProtossUnit에 의존하게 되는겁니다.

결국, 처음에는 UnitMaker가 유닛들에 의존했지만 이제는 그 의존성이 뒤집히게 된겁니다.

OCP랑 헷깔리는 DIP는 아주 이해하기 힘듭니다.. 나중에 DIP만 따로 정리를 할 필요가 있는거 같아요 ㅠㅠ