들어가기에 앞서... 지난 글에서는 DIP 원칙이란 무엇인지, 또 DIP의 장점과 적용하는 방법에 대해서 설명했다. 해당 원칙대로 작성한 코드는 순환 참조 문제에 빠질 일이 없고 객체지향적으로써 바람직한 코드가 될 것이다. DIP 원칙 그 자체로써는 단점이 거의 없다.(아주 없지는 않다. 코드의 길이가 살짝 늘어난다. 물론 이러한 단점은 장점에 비하면 매우 사소하다.) 이 글의 제목이 '단점'이 아닌 '한계'라는 사실에 주목하라. 그렇다면 이 글에서 설명하고자 하는 한계는 무엇인가? 바로 DIP 원칙을 적용할 수 없는 경우이다. 상위 폴더에 인터페이스를 두기만 하면 DIP 원칙이 적용된다고 생각할 수 있고 또 어느 정도는 사실이지만, 이것이 불가능한 경우가 존재한다. 이 글에서는 DIP 원칙을 적용할 수..

들어가기에 앞서... 해당 글은 독자가 Go 언어(혹은 C언어 계열)의 문법에 대한 기본 지식이 있다고 가정하고 설명하겠다. 객체지향적 설계에 관해 집중적으로 공부한 적이 있다면 'SOLID 원칙'이라는 용어는 들어봤을 것이다. SOLID 원칙은 로버트 마틴이 그의 저서 '클린 소프트웨어'에서 제창한 용어로 다섯 가지 객체지향 소프트웨어 디자인 원칙의 약자를 모은 것이다. 이번 글에서는 이 다섯 가지 원칙 중 마지막 원칙인 DIP(의존성 역전 원칙)에 대해 설명할 것이다. 해당 원칙은 이해하기가 어려운 대신, 이해만 한다면 (특히 Go언어에서)바로 적용하기 쉬운 유익한 원칙이다. 정의 상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 추상화는 세부 사항에..