SOLID 원칙

#1 프로그램의 운명과 설계

인간의 운명은 명확하다. 특이점이 오지 않는다는 가정하에, 인간은 언젠간 반드시 죽는다. 프로그램의 운명도 명확하다. 한 번 개발된 프로그램은, 미래에 반드시 변경(유지보수)된다.

 

'운명'을 고려하면 프로그래밍에서 '좋은 설계'가 무엇인지 떠올릴 수 있다. 바로, 변경에 강한 설계(구조)다. 아래에 있는 말은 다 같은 말이다.

 

변경에 강한 설계(구조)
= 새로운 요구사항이나 변경 사항이 있을 때, 바꿔야 하는 코드의 범위가 좁은 구조
= 변경에 유연하게 대처가 가능한 구조
= 확장성이 높은 구조

 

#2 SOLID 원칙

#2-1 WhatㆍWhy

• 위키백과: SOLID (객체 지향 설계)
• 카카오뱅크: 모든 개발자가 알아야 할 SOLID의 진실 혹은 거짓
• Inpa Dev: 객체 지향 설계의 5가지 원칙 - S.O.L.I.D

#1에서 말한 '변경에 강한' 코드를 만들기 위해 고안된 5가지 패턴(원칙)이다. S,O, L, I, D의 각 알파벳이 패턴 하나에 대응한다. 

 

#2-2 이모저모

• 객체 지향 프로그래밍의 단골 면접 질문 중 하나다.
• 현대의 많은 디자인 패턴이 SOLID 설계 원칙에 따라서 만들어졌다. (SOLID가 근간).
• 눈에 띄는 철자로 만들기 위해 S → O → L → I → D 순으로 배열되었을 뿐, 5원칙 간 우선순위는 없다.
• 5가지 원칙들은 서로 완전히 독립된 개별적인 개념이 아니라 개념적으로 연관되어 있다. 원칙끼리 서로서로 이용하기도 하고 일부 경우에선 포함 관계를 이룰 수 있다.
• 코드에 문제가 없다면 억지로 지키지 않아도 된다. 또 S, O, L, I, D 전부가 아니라 일부만 지켜도 된다. (형식보단 기능!).

 

#3 [S] 단일 책임 원칙

Single Responsibility Principle, SRP

 

#3-1 What

하나의 클래스는 하나의 '책임'만을 지녀야 한다.

* 책임(Responsibility): 존재 의의 (역할, 기능 등)

만약 하나의 클래스에 기능(책임)이 여러 개 있다면, 기능 변경(수정)이 일어났을 때 수정해야 할 코드가 많아진다. 내가 설계한 클래스가 만약 미래에 변경된다면, 그 이유는 한 가지 종류의 '책임(Responsibility)' 때문이어야 한다.

 

#3-2 'Ripple Effect'란

UI 디자인에서는, (버튼 클릭 시 등 때의) 시각적 물결(Ripple) 효과를 의미한다. 프로그래밍에서는 다른 하나는 코드 변경 시 예기치 않게 발생하는 코드의 연쇄적인 영향(파급 효과)을 의미한다. 여기서는 Ripple Effect를 후자의 의미로 사용한다.

 

#3-3 예시ㆍ기대 효과

SRP를 지키지 않은 예시

기능(책임)을 여러 개 가진 클래스 A가 있을 때,
A의 특정 기능을 변경하면
→ 연관된 클래스 B 수정
→ 연관된 클래스 C 수정
→ 연관된 클래스 D 수정

Ripple Effect가 발생하는 예시다. 위의 예시에서 더 나아가 만약 D의 수정 사항이 A에게 Ripple Effect를 일으킨다면, Ripple Effect가 A에서 시작해서 A로 돌아오는 순환 형태가 되고 만다. 혼돈 그 자체다. 만약 SRP를 준수했다면 코드 변경이 하나의 클래스 내부로 한정되었을 것이다 (= Ripple Effect가 발생하지 않았을 것이다).

 

기대 효과

SRP 패턴을 준수하여, Ripple Effect를 방지할 수 있다.

 

#4 [O] 개방 폐쇄 원칙

Open Closed Principle, OCP

 

#4-1 What

(인터페이스나) 부모 클래스의 자식 클래스를 만들 때, 기존 코드(부모 클래스)를 수정할 필요가 없어야 한다.

이를 달성하기 위해서, 부모 클래스에는 '최소한의 추상화(#4-2) 코드'만을 남기고 나머지는 제거해야 한다.

 

#4-2 '추상'이란

• 표준국어대사전: 여러 가지 사물이나 개념에서 공통되는 특성이나 속성 따위를 추출하여 파악하는 작용 (링크)
• 그래디 부치(Grady Booch): 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징

여기에선 '추상'을 묘사할 때 일반적으로 통용되는 설명을, #4-4에선 '추상'의 본질적인 설명을 다룬다. 추상은 '공통된 것'이라고 설명되는 게 일반적이다. 우리가 그림 '회색 나무'에 있는 물체를 '나무'라고 인식하는 이유는, 그 그림에서 현실의 나무들이 공통으로 지니는 특성을 식별할 수 있기 때문이다.

 

#4-3 예시ㆍ기대 효과

OCP를 지키지 않은 예시

open class Animal {
    // 새로운 동물(예: Fox)을 추가하려면 이 when 문을 반드시 수정해야 함 → OCP 위반
    fun speak(animal: Animal): String {
        return when (animal) {
            is Dog -> "왈"
            is Cat -> "냥"
            else -> "..."
        }
    }
}

class Dog : Animal()

class Cat : Animal()

위의 코드를 #4-2에 있는 '추상' 개념으로 설명하자면, 동물들은 공통으로 소리를 낸다(Speak)는 특성을 코드(Animal.speak())로 옮긴 것이다. 하지만 그 추상을 최소화하지 않았다. 다시 말해, speak() 부분의 코드가 과도하게 많다. 그래서 Animal이라는 부모를 따르는 Cat, Dog 클래스의 speak() 메소드 구현을 위해선, '기존 코드(여기선 Animal의 코드)를 고쳐야 하는' 상황이 되어버렸다.

 

OCP를 지킨 예시

// 위의 코드를 수정해 OCP 준수하게 만듦
open class Animal {
    open fun speak(): String = "..."
}

class Dog : Animal() {
    override fun speak() = "왈"
}

class Cat : Animal() {
    override fun speak() = "냥"
}

---

// 이렇게 Animal을 interface로 두는 방식의 수정도 좋다
interface Animal {
    fun speak(): String
}

class Dog : Animal {
    override fun speak() = "왈"
}

class Cat : Animal {
    override fun speak() = "냥"
}

반면 speak()을 '최소화된 추상 코드'로 바꾸면 어떨까? 기존 코드를 바꾸지 않고도 Cat, Dog 등을 선언 가능할 만큼 speak()을 경량화했다. 따라서 위의 코드는 OCP를 지킨 코드가 된다.

 

기대 효과
OCP 패턴을 준수하여, 기존 코드 수정 없이 손쉽게 기능 확장이 가능해진다.

 

#4-4 진짜 '추상'

본질(What) 찾기

추상 = 구조 = 정책
(추상화 = 구조화 = 정책화)

#4-2에선 '추상'을 묘사할 때 통용되는 설명을 다뤘지만, 여기에선 '추상'의 본질적인 설명을 다룬다. 사실 추상이란, 그냥 '구조'에 불과하다. #4-2에서 언급했던 '공통'이라는 키워드도 여기엔 없다. 두 글자 '구'와 '조'가 설명의 전부다. 나는 추상이 그저 '구조'의 현학적 표현에 불과하다고 감히 주장해 본다. 아래는 사람을 '추상화한' 그림 2개에 대한 비교다.

 

어째서 졸라맨은 팔과 다리가 있는데, 화장실 표지판 사람에겐 없는가? 일반적인 사람은 누구나 공통으로 가지는 게 아닌가? 이 반례를 통해 추상이란 (디자이너가 임의로 정한) '구조'를 어렵게 표현한 단어일 뿐이지, '공통'을 들먹이며 설명할 필요가 없는 개념임을 알 수 있다. 그렇다면 왜 그런 설명이 나오게 되었을까? 그것은 바로 What과 How를 혼동했기 때문이다.

 

추상은 무엇(What, 본질)인가? → 구조
추상을 어떻게(How, 방법) 해야 잘 뽑아내는가? → 공통점을 찾아서

이렇듯, What에 대해 설명해야 하는데 How에 대한 설명을 해버린 것이다. 물론 일반적으로 통용되는 설명에서, 추상을 '구조'라고 할 수 없는 노릇인 것도 인정한다. 너무 짧아서 무성의하게 보일 것이기 때문이다. 아래와 같이 반문할 수도 있다.

 

졸라맨과 화장실 표지판 사람 모두 '사람'이라면 공통으로 가지고 있는 '머리'를 동그라미로 표현했는데, 반례랍시고 제시한 예시마저도 결국 공통의 개념이 들어가 있는 것이 아닌가?

그렇다면 사람 머리를 네모로 표현하는 추상은 어떤가? 아니면 아예 머리부터 발끝까지를 통째로 하나의 점(.)으로 표시할 수도 있고, 특정한 숫자로 표시할 수도 있다. 어떤 형태든 그건 디자이너의 마음이다. 일반적으로 추상을 '잘' 하기 위해서 '공통'점을 잘 뽑아내야 하는 건 맞지만, 앞서 말했듯 그건 추상의 How지 What이 아니다.

 

좋은 방법(How)

지금까지 일반적으로 통용되는 추상의 정의에서 본질(What)과 방법(How)을 분리했다면, 지금부턴 분리된 부분 중 How를 집중적으로 공략해본다. 다시 말해 어떻게 해야 추상화를 잘할지에 대한 설명이다. 좋은 추상은 2가지 요소의 줄다리기에서 나오는데, 그 요소는 아래와 같다.

 

1. 유연함 (공통점을 좁게 잡음 = "xxx 중 일부만이 그래")
2. 가독성 (공통점을 넓게 잡음 = "xxx는 다 똑같아")

이 요소와 함께 #4-3의 예시를 다시 보자. Animal은 소리를 내는 공통점이 있다고 했지만, 정말로 그럴까?

 

class Shell : Animal() { // 조개
    override fun speak() = "???" // 논리적 에러
}

이 코드에서는 논리적 오류가 난다. 조개는 동물이지만 소리를 낼 수 없다. 이 오류가 발생한 것은, 모든 동물이 말할 수 있다는 식으로 공통점을 너무 넓게 잡았기 때문이다. 비슷하게 모든 차(Car)에는 바퀴가 있다고 공통점을 잡으면, 탱크의 경우를 처리하지 못하게 된다. 모든 사람에게 머리카락이 있다고 공통점을 잡아버리면, 탈모 인구를 커버하지 못하게 된다.

 

open class Animal

open class SpeakableAnimal : Animal() {
    open fun speak(): String = "..."
}

class Dog : SpeakableAnimal() {
    override fun speak() = "왈"
}

class Cat : SpeakableAnimal() {
    override fun speak() = "냥"
}

class Shell : Animal() // 조개

모든 Animal이 speak()을 할 수 있다고 하는 대신, 더 좁은 범위인 SpeakableAnimal만이 speak()을 할 수 있게 했다. 즉, 공통점의 범위를 줄였다. 공통점을 줄이면 유연성이 생기지만, 공통점을 줄인 만큼 생긴 차이점에 관해 기술해야 하기 때문에 코드양이 늘어나서 가독성은 떨어진다.

 

모든 동물은 울음소리를 낸다 → 일부 동물만이 울음소리를 낸다

와 같이 공통점의 범위를 좁혔더니, 유연함이 증대됐고 코드양이 늘어나서 가독성은 하락했다. 만약 반대 방향으로 공통점의 범위를 넓혔다면, 유연함이 감소했을 것이고 코드양이 줄어들어 가독성은 향상되었을 것이다. 어느 방향이건 극단으로 가면 안 좋다는 걸 직감적으로 느낄 수 있다. 두 극단 사이에서 균형을 잡는 데에는, 숙련된 프로그래머의 노련한 감각이 분명히 요구될 것이다.

 

#4-5 TMI

#4-4에서 말한 졸라맨을 다시 보자. 왜 (화장실 표지판 사람과 달리) 졸라맨은 사지가 멀쩡할까? 졸라맨은 주로 교과서 구석 낙서에 나오는 등장인물이고, 디자이너는 십중팔구 수업 시간이 지루해서 낙서 중인 초등학생이다. 그런 초등학생들의 99%는 졸라맨들끼리 싸우는 모습을 그릴 텐데, 싸움 묘사를 위해 팔과 다리의 존재는 필수적이다. 

 

졸라맨에게 강제로 유연함을 부여하면 어떻게 될까? 졸라맨의 몸통은 일직선이다. 여기서 일직선 대신 화장실 표지판 사람처럼 '거대한 몸통'을 그려 넣게 강제해 보는 것이다. 초등학생의 반응은 아마 이럴 테다: "그냥 졸라맨끼리 싸우는 것만 그리고 싶은데, 귀찮게 몸통도 그려 넣어야 해? 차라리 수업을 듣고 말지!". 졸라맨은 더 건들일 필요 없는 최소한의 추상이니까.

 

한편, 화장실 표지판 사람은 싸울 일이 없다. 간혹 화장실 표지판에서 팔과 다리를 묘사하는 때도 있으나, 그런 상황에도 팔과 다리는 어차피 아무런 동작도 의미도 없다. 또 화장실 표지판 사람들은 몸통이 반드시 일자가 아니다. 만약 일직선이라면 남자 화장실인지 여자 화장실인지의 표시를 위한 색을 채워 넣을 수 없기 때문이다. 화장실 표지판 또한 세월이 흐르며 정형화된 최소한의 추상이다.

 

#5 [L] 리스코프 치환 원칙

Liskov Substitution Principle, LSP

 

#5-1 What

하위 타입은 상위 타입으로 대체할(치환) 수 있어야 한다.

상속받은 자식 클래스는 부모 클래스처럼 다뤄도 논리적으로(='기능'적으로) 똑같이 동작해야 한다. 구현체(자식)를 바꿔도 코드의 의미(메소드별로 지니는 동작의 추상적인 기대)가 깨지지 않아야 한다는 말이다.

 

#5-2 '캐스팅'이란

한 타입을 다른 타입으로 변환하는 것. 객체지향에서는 주로 상속 관계에서 사용됨. 즉, 부모 클래스 ↔ 자식 클래스 간의 형 변환을 의미한다.

 

업캐스팅

val dog = Dog()
// "as" 없이 업캐스팅 (암시적)
val animal: Animal = dog
animal.sound()

자식 클래스의 객체(인스턴스)를 부모 클래스 타입으로 형 변환하는 행위. 항상 안전하며 자동으로(= 암시적으로) 수행할 수 있다.

 

다운캐스팅

val animal: Animal = Cat()
// 다운캐스팅 (명시적). "as"에서,
// ClassCastException 발생 가능성 있음
val dog = animal as Dog   
dog.bark()

부모 클래스의 객체(인스턴스)를 자식 클래스 타입으로 형 변환하는 행위. 안전이 보장되지 않으며 명시적 캐스팅이 필요하다.

 

#5-3 의문점?

자식은 부모의 메소드를 오버라이드해서 만들어지므로, 업캐스팅이 무조건 가능(안전)하다. 즉, 리스코프 치환 원칙은 알아서 지켜지는 게 아닌가?

아니다. 핵심은 업캐스팅이 아니라 '기능'이다

 

open class Bird {
    open fun fly() { println("날아요") }
}

class Ostrich : Bird() {
    // 자식이 부모의 '기능'(비행) 수행 불가
    override fun fly() { 
        throw UnsupportedOperationException(
            "타조는 못 날아요"
        )
    }
}

부모(Bird) 쪽에서 fly() 메소드를 정의함으로써 ("새는 날 수 있다"라는) '기능'을 보장했는데, 자식(Ostrich)이 그 보장을 깨버렸다. 즉, Ostrich는 LSP를 위반했다. 혹은 이런 상황을 만든 프로그래머가 LSP를 위반했다.

 

#5-4 예시ㆍ기대 효과

LSP를 지킨 예시

자바의 LinkedList, ArrayList, HashSet 등은 모두 Collection 인터페이스를 구현한다. 그리고 각 자료형을 Collection 타입으로서 다루더라도 (= 업캐스팅), Collection.add() 나 Collection.contains() 같은 메서드가 정상적으로(= 프로그래머가 기대하는 논리적 '기능'에 맞게) 동작하므로 LSP를 지킨 사례라고 할 수 있다.

 

LSP를 지키지 않은 예시

반면 런타임 에러가 나지 않는대도 add(), contains() 등의 동작이 논리적으로 이상하다면, 그것은 LSP를 위반한 것이다.

 

기대 효과

LSP 패턴을 준수하여, 객체의 구체적인(= 다형적인) 구현에 의존하지 않게 만든다. 그래서 객체 교체를 자유로이 만든다. (다형성^Polymorphism ↑).

 

#6 [I] 인터페이스 분리 원칙

Interface Segregation Principle, ISP

 

#6-1 What

클라이언트가 필요 없는 기능에 의존(implement)하지 않게, 의존할 인터페이스ㆍ클래스 구조를 잘 나눠 설계한다.

* 클라이언트(Client): 인터페이스나 다른 클래스의 기능을 끌어다 쓰는 클래스 (정확한 비유는 아니지만, 클래스 계의 getter 느낌)

객체는 오직 자신이 필요한 '추상'(#4-2, #4-4)에만 의존해야 한다. 추상화를 정의하는 것은 인터페이스이므로, 인터페이스를 잘 분리하면 ISP가 지켜질 것이다. 여기서 "잘 분리한다"라는 것의 의미는 그저 조그맣게 나누면 OK라는 게 아니라, '추상'(#4-2, #4-4)에 맞게 잘 나누라는 얘기다.

 

#6-2 용어 정리

클래스: 구체적인 기능 구현
인터페이스: 구현 없이 기능ㆍ형식만을 정의
클라이언트: 클래스 / 인터페이스를 사용하는 주체인 객체

 

#6-3 예시ㆍ기대 효과

ISP를 지킨 예시

Kiosk가 LotteriaOrderSystem 및 LotteriaBurgerMenu 대신 OrderSystem 및 BurgerMenu에 의존하는 이유는 DIP 원칙을 지키기 위함이다. 만약 Kiosk가 BurgerMenu가 아닌 FastfoodMenu를 상속받는 구조였다면(= 의존한다면 = implement 한다면) 피자 메뉴에 대해서 "주문할 수 없는 메뉴입니다."를 출력하는 코드를 일일이 귀찮게 넣어주어야 했을 것이다.

 

기대 효과

ISP 패턴을 준수하여, 의미 없는 예외 처리를 하지 않게 만드는 구조를 형성한다.

 

#6-4 포함 관계 정리

"ISP를 지키면 SRP가 따라온다." → △

항상 그렇진 않지만, 대체로 맞다. 인터페이스가 작으면, 해당 인터페이스를 상속받는 클래스가 구현할 기능도 작을 확률이 높다. 그러면 당연히 '책임이 한 가지일 확률'도 높아진다. 아래는 '항상 그렇지 않은' 이유를 설명하기 위한 코드다 (반례).

 

class FileManager : Readable, Writable {
    override fun read(): String {
        ...
    }
    override fun write(data: String) {
        ...
    }
}

'클라이언트'로서의 FileManager는 자신이 사용하지 않는 메서드에 의존하지 않는다 (ISP 준수). 하지만, '클래스'로서의 FileManager는 (관점에 따라 '파일 관리'라는 단일 책임으로 볼 수도 있긴 하지만) '파일 읽기'와 '파일 쓰기'라는 2가지 책임을 보유한다. 이 관점에서는 클래스의 잠재적 업데이트 이유가, "파일 읽기 로직을 수정할 필요가 있을 때"와 "파일 쓰기 로직을 수정할 필요가 있을 때"의 2종류이므로 SRP를 위반하게 된다.

 

"SRP를 지키면 ISP가 따라온다." → ✕

interface Board {
    fun write()
    fun read()
    fun update()
    fun delete()
}

위의 인터페이스가 지닌 기능을, '게시글 이용'이라는 '단일 책임'으로 보기로 가정(약속)하고 아래의 코드를 읽어보자.

 

class AdminUser : Board {
    override fun write() {
        println("관리자가 글을 씀.")
    }
    override fun read() {
        println("관리자가 글을 읽음.")
    }
    override fun update() {
        println("관리자가 글을 수정함.")
    }
    override fun delete() {
        println("관리자가 글을 삭제함.")
    }
}

class NormalUser : Board {
    override fun write() {
        println("일반 사용자가 글을 씀.")
    }
    override fun read() {
        println("일반 사용자가 글을 읽음.")
    }
    override fun update() {
        println(
            "일반 사용자가 글을 수정함."
        )
    }

    // 필요없는 구현을 강요당함 (ISP 위반)
    override fun delete() {
        throw UnsupportedOperationException(
            "일반 사용자는 게시글 삭제 불가."
        )
    }
}

NormalUser.delete()는 명제에 대한 반례다.

 

#7 [D] 의존 역전 원칙

Dependency Inversion Principle, DIP

 

#7-1 부정확한 설명

어떤 클래스에 의존(참조)하는 대신, 그 클래스의 가능한 높은 부모(클래스, 인터페이스)에 의존(참조)한다.

객체 지향 프로그래밍에선 자식 쪽으로 갈수록 '구현'이 강해지고, 부모 쪽으로 갈수록 '추상화'가 강해지는 구조가 자연히 형성된다. 이때 되도록 내가 다루는 객체가 자식 쪽보다는 부모 쪽에 의존하게 만들어라. 다시 말해, 구현보단 추상화에 의존하게 만들어라. 비유하자면, '의존의 업캐스팅(#5-2)'을 하라는 말이다. 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는, 변화하기 어려운 것 거의 변화가 없는 것에 의존하라는 것이기도 하다.

 

위의 설명은 이해 난이도 측면에서, 그리고 'DIP가 대충 어떤 느낌인지' 파악하기에는 좋다. 하지만 (내가 쓴 거지만) DIP를 부정확하게 왜곡한 설명이다. #7-3에서 이어서 설명한다.

 

#7-2 '역전'의 의미

옛날 프로그래밍의 정석: 고수준 로직이 저수준 유틸리티를 호출(의존)하는 게 자연(직관)스럽다
↓
객체 지향 프로그래밍 도입 후 정석: 저수준 구현이 고수준의 추상 정책을 따르는(의존하는) 게 (유지보수 상) 편하다

[상위 모듈 → 하위 모듈]에서 [하위 모듈 → 상위 모듈]로 의존 방향의 정석(패러다임)이 역전됐다는 의미다. 이어지는 #7-3에서 '역전'의 더 직관적인 의미를 '보여'주겠다.

 

#7-3 What (정확한 설명)

#7-1의 설명이 부정확한 이유를 나열해 보겠다.

 

"부모에 의존하라." → ✕

프로그래밍에서 '부모'는 원래 '상속 관계'에서의 상위 클래스를 의미한다. 아래는 DIP의 원문이다.

A. High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
B. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

DIP의 원문에선 추상(= 구조 = 정책 = 인터페이스)에 의존하라고 했다. 이를 '부모'라고 불러선 안 된다. 물론 객체 지향 프로그래밍에선 (상속 관계에서) 자식 쪽으로 갈수록 '구현'이 강해지고, 부모 쪽으로 갈수록 '추상화'가 강해지는 구조가 자연히 형성된다. 때문에 그렇게 부를만한 경향성 자체는 존재한다. 그렇다, 그저 '경향성'에 불과한 것이다.

 

"부모(인터페이스)" → ✕

어떤 인터페이스 A를 구현하는 클래스 B가 있을 때, A를 B의 '부모'라거나 반대로 B를 A의 '자식'이라고 부를 수는 없다. 아래의 용어 정리를 보자.

서브타이핑(subtyping): B가 A를 구현하거나 확장하여, "A를 기대하는 위치(where A is expected)"에 B를 둬도 안전하게 대체(substitute)되는 관계로 만드는 것 (B를 A의 subtype으로 만드는 행위).

상속(inheritance): 구현(implementation)을 물려받으며 서브타이핑하는 것.

인터페이스 구현(implementation of interface): 인터페이스를 서브타이핑하는 것. 인터페이스는 가진 구현(implementation)이 없어, 서브타이핑 시 구현을 새로 만들어야만 하므로 상속이 아님.

* 그렇다면 인터페이스를 서브타이핑해 새로운 인터페이스를 만드는 건 뭐라고 부를까? 바로, '인터페이스 확장(interface extension)'이라 부른다. 하지만 위키백과에 따르면 일부에선 '인터페이스 상속(interface inheritance)'이라는 표현도 쓴다고 한다. 후자의 경우여도, inheritance라는 단어 앞에 interface라는 단어가 있으므로 크게 헷갈릴 염려는 없을 것이다. 

부모-자식 관계는 상속 관계를 의미하는데, 인터페이스는 상속 관계가 아니라서 '부모'가 될 수 없다.

 

"가능한 높은 부모정책에 의존하라." → ✕

'부모'라는 말은 앞서 틀린 이유를 설명했으니, "가능한 높은 부모에 의존하라"라는 표현을 "가능한 높은 정책에 의존하라"로 고쳤다. 그러나 이렇게 고쳐도 틀린 표현이다. 왜냐하면 '높은'이라는 단어는 상속 관계에서나 쓰는거니까. 따라서 이렇게 말해야 한다: "가능한 정책에 의존하라".

 

'상위 모듈 및 하위 모듈'에 대한 언급 없음 → ✕

원문에는 상위 모듈이나 하위 모듈에 대해 "Both should depend on abstractions"라고 되어 있다. 둘 다 정책에 의존하라는 얘기다. 여기서 주의할 점은, 무의식적으로 상위 모듈하고 하위 모듈이 부모-자식 관계라고 착각하는 것이다. 물론 DIP 이전 즉, #7-2에 있는 '옛날 프로그래밍의 정석'대로라면 부모-자식 관계인 것이 자연스럽다. '옛날 프로그래밍의 정석'대로였다고 하더라도 그렇게 착각해선 안 된다. 왜냐하면 옛날 프로그래밍 관점에서, '상위' 모듈하고 '하위' 모듈은 '의존성' 측면에서 구분해 둔 것이기 때문이다. 자식 클래스는 부모 클래스에 자동으로 의존하게 되는 건 맞지만, 반대로 의존성이 있다고 반드시 부모-자식 관계인 것은 아니다. 결론은, 옛날 프로그래밍 방식이었다면 의존성 그래프상에서 이어져 있었을 두 모듈의 의존성을 제거하고, 두 모듈 '각각' 정책에 의존시키라는 것이다. 이를 의존성 그래프로 표현하면 아래와 같다.

 

그래프 1에서는 화살표가 아래로, 즉 상위 레벨 모듈에서 하위 레벨 모듈로 내려가지만, 그래프 2로 오면서 상위 레벨 모듈과 하위 레벨 모듈 간의 직접 의존이 없어지면서 그렇지만은 않아졌다. 그래프 3은 그래프 2와 (논리적으로) 완전히 동일한 그래프인데, 화살표가 위를 향하도록 '정책' 노드의 배치만 바꾼 것이다. 그래프 3처럼 '정책' 노드를 '구현' 노드보다 위쪽 공간에 배치하는 게 의무 사항은 아닐 것이다. 하지만 자연스럽다. 마치 어떤 계획이든 가이드라인을 먼저(= 상위에) 세운 다음에서야 세부 구현을 짜는 우리들의 모습이 겹쳐 보이기 때문이다. 그렇기에 나는 그래프 3의 모습이 '역전'을 직관적으로 '보여'준다고 생각한다. 아래로만 향했던 그래프 1속의 화살표가, 그래프 3에서는 반대로 역전되어 위로만 향하고 있는 모습 말이다.

 

그렇다면 최종으로, 정확한 설명은?

상위 모듈은 하위 모듈(= "어떻게 해야 하는가?")에 직접 의존하는 대신, 하위 모듈이 의존하는 추상(인터페이스, 정책)(= "무엇을 해야 하는가")에 의존한다.

 

#7-4 예시ㆍ기대 효과

DIP를 지킨 예시

롯데리아가 맥도날드를 인수한 세계가 존재한다고 해보자. 그리고 이 세계에서 롯데리아 측은 롯데리아 매장에서도 맥도날드의 햄버거를 제공하기로 했다. 그래서 전국 롯데리아 매장에 있는 키오스크 일부를 맥도날드 메뉴 전용 키오스크로 바꾸기로 한다.

하지만 키오스크 담당 프로그래머는 웃고 있다(?). 왜냐하면 Kiosk 클래스가 LotteriaBurgerMenu가 아닌, (DIP를 준수하여) BurgerMenu에 의존하도록 두었기 때문에 (비교적) 수월하게 맥도날드 메뉴용 키오스크로 전환할 수 있기 때문이다.

 

기대 효과
DIP 패턴을 준수하여, 클래스 간 결합도(Coupling)를 낮출 수 있다.

 

#7-5 포함 관계 정리

"DIP를 지키면 LSP가 따라온다." 또는 "LSP를 지키면 DIP가 따라온다." → ✕

둘 다 결합도를 낮추는 건 맞지만, 어느 쪽이 어느 쪽을 포함하는 관계는 아니다. DIP는 추상 중심의 설계 구조 확립을 위함이고, LSP는 상속 관계의 클래스들의 추상 '기능'이 일관성을 유지하게 만들기 위함이다.

 

TMI: "LSP를 지키면 DIP를 지키기 쉽다." → ○

'구현'(자식 쪽) 대신 ''추상'(부모 쪽)에 의존하기 위해선 (= DIP 준수), 자식을 실제로 부모로 대체 가능(= LSP 준수)해야만 의미가 있게 되기 때문이다.