Intellectual Wanderlust

OOP에 대해서, 아는 사람은 다 알만한 이야기 및 이 글에서 인용하고 있는 大山님의 글 객체지향 프로그래밍에 대한 오해와 진실 1편, 2편을 읽고 씁니다(3년 전 글입니다). 딱히 관련 글이라기 보다는 읽고 떠오르는 생각들 몇 가지 + 제가 평소에 가지고 있던 생각을 늘어 놓으려고 합니다.

OOP를 바라보는 (유일하게 올바른 관점이 아닌 다양한 관점 중) 한 가지 관점에 대해 쓰고자 합니다. 하나의 대상을 한 측면에서만 보는 것 보다는 여러 측면에서 보면 좀 더 그 대상에 대해서 잘 알 수 있을 것이라고 생각하기 때문입니다. 제가 제시하고자 하는 관점은 다음과 같습니다:

“OOP는 무엇을 제거 혹은 대체하고자 하는가?”

 

1. 레퍼런스와 포인터 산술연산

예를 들어 자바나 C#의 레퍼런스(reference) 개념을 살펴보죠. 레퍼런스는 보안성, 편의성, GC 효율성 등을 향상시키기 위해 기존의 포인터 개념으로부터 산술연산(arithmatic operations)을 제거하였습니다. (결과적으로 보안성, 편의성, GC 효율성 등이 향상 되었는지 아닌지에 대한 판단은 각자 알아서)

포인터는 전지전능한 주소지칭 수단인데, 사실은 전지전능한 주소지칭 수단이 없어도 모든 프로그램을 작성할 수 있다는 것을 알게 된 것이죠(성능 이슈 등을 제외한다면).

 

2. 구조적 프로그래밍과 GOTO

또 다른 예로, 구조적 프로그래밍은 프로그램의 흐름을 제어하는 방법 중 goto를 제거(다익스트라 식으로 표현하자면 의미있는 프로그래머 독립 좌표계 – programmer independent coordinates - 를 훼손하는 장치들을 제거)하였습니다. 구조적 프로그래밍에서는 다음 세 가지 수단만으로 모든 프로그램의 흐름 제어를 구현해냅니다:

• 순서(sequence) – 쉽게 말해서 코드가 위에서 아래로 실행되는 것
• 선택(selection) – 쉽게 말해서 if와 switch
• 반복(iteration) – 쉽게 말해서 while(혹은 do, until, for 등)

조건문(if)과 결합된 goto 문은 전지전능한 흐름제어 수단인데, 사실은 전지전능한 흐름제어 장치가 없어도 모든 프로그램을 작성할 수 있다는 것을 알게 된 것이죠(성능 이슈 등을 제외한다면).

 

3. OOP와 무엇?

드디어 본론인데요, OOP는 뭘 제거(혹은 대체)하였을까요? 혹자는 OOP가 구조적 프로그래밍을 대체한다고 말하는데 1/3 쯤 맞는 표현이라고 생각합니다. OOP는 구조적 프로그래밍의 세 가지 흐름 제어 수단(sequence, selection, iteration) 중에서 선택(selection) – 즉 if 문 – 을 제거합니다.

구조적 프로그래밍에 대한 설명에서 “조건문(if)과 결합된 goto 문은 전지전능한 흐름제어 수단”이라고 표현하였는데 이 중 goto는 제거되었으나 if는 살아남은 것이 구조적 프로그래밍이라면 if 까지도 제거하고자 하는 흐름을 OOP라고 보는 관점이 있을 수 있다는 것이죠.

오해의 소지가 있으니 잠깐 부연하자면, 모든 if를 제거해야 진정한 OOP라는 류의 주장은 아닙니다. 이에 대해서는 글 뒷부분에서 좀 더 이야기하도록 하겠습니다(진정한 OOP 따위 대체 뭔가요, 먹는거임? 우걱우걱).

그럼 조건문을 무엇으로 대체하고 있나요? 다형성(polymorphism)이죠. 그냥 다형성이라고 하면 너무 광범위하죠. 이를테면 파라메터 다형성(parametric/parameterized polymorphism)은 OOP 보다는 Generic Programming과 관련이 있습니다. OOP의 핵심이라고 하는 다형성은 특히나 서브타입 다형성(subtype polymorphism)을 말합니다. 이후에는 그냥 다형성이라고만 쓰겠습니다.

그럼 다형성이 조건문을 어떻게 대체하나요? 조건문이란 애초에 선택(selection)을 위한 것인데, 여기에서 선택이란 특정 변수의 값에 따라 이후에 실행할 코드가 달라지도록 하는 것을 말합니다. if 문에서는 조건절의 boolean 값에 따라 선택이 수행되는 것이고, 다형성에서는 메시지(message)에 담긴 파라메터(메시지를 받는 대상 개체도 파라메터로 칩시다. 파이선 self 마냥)에 따라 선택이 수행됩니다.

4. 다형성과 의존성 역전(DI – Depedency Inversion)

if를 다형성으로 대체하는 것이 정말 OOP를 특징지을만큼 중요한가요? 네, 전 그렇다고 생각합니다. 이쯤에서 밥 삼촌(Uncle Bob)을 인용해주어 (올바른) 권위에의 호소를 한 번 시도하도록 하겠습니다:

프로그램이 어떤 언어로 작성되었는지는 중요치 않습니다. 만약 의존성이 역전되어 있다면 이는 객체지향적 설계인 것입니다(It doesn't matter what language a program is written in. If its dependencies are inverted, it has an OO design).

--Robert Cecil Martin, Agile Software Development

if 얘기 하다말고 갑자기 왜 의존성 역전(DI) 떡밥이 나왔을까요? 그 전에, 애초에 의존성 역전이라고 할 때 이 역전이란 뭘 뒤집었다는 뜻일까요? David Parnas 큰형님이 지금으로부터 무려 37년 전에 쓴 논문에 답이 나옵니다:

첫째, 하위 계층의 서비스를 활용함으로써 시스템의 일부가 이득을 취했다(간결해졌다). 둘째 상위 계층을 들어내더라도 여전히 유용하고 사용 가능한 산출물(하위 계층 서비스들)이 남는다. (…중략…) 만약 하위 계층의 모듈이 상위 계층의 모듈을 사용하게끔 설계를 했다면 올바른 위계를 얻어낼 수 없었을 것이고 시스템의 일부만 들어내기가 훨씬 더 어려웠을 것이며, 계층이라는 말 자체가 의미를 잃게 될 것이다(First, parts of the system are benefited (simplified) because they use the services of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product. (..omitted...) If we had designed a system in which the "low level" modules made some use of the "high level" modules, we would not have the hierarchy, we would find it much harder to remove portions of the system, and "level" would not have much meaning in system).

--On the Criteria to be used in Decomposing Systems into Modules

시스템을 모듈화할 때 계층 간의 위계를 명확히 나누고 상위 계층이 하위 계층을 사용(즉 의존)하도록 만들어야 한다는 주장이며 이는 구조적 프로그래밍 혹은 모듈화 프로그래밍의 핵심 설계 원칙 중 하나입니다. 여기에서 상위 계층이란 좀 더 추상적인(abstract) 계층을 말하고 하위 계층이란 좀 더 구체적인(concrete) 계층을 말합니다. 그림으로 그려보면 아래와 같습니다:

모든 화살표가 위에서 아래로 내려가는 모습을 담고 있습니다. 의존성 역전이란 바로 이러한 의존관계를 뒤집는다는 의미로, 의존성 역전이 일어난 설계에서는 화살표 일부가 아래에서 위로 올라갑니다. UML로 치자면 속이 빈 삼각형 화살표(generalization 혹은 realization)로 표현합니다:

의존성 역전이 가능한 이유는 하위 계층이 상위 계층에 의존하면서도 순환 참조(circular dependency)가 일어나지 않게 만들어서 이를 통해 원래 David Parnas가 강조하던 목적(시스템의 일부를 쉽게 들어낼 수 있도록 하는 것)을 여전히 달성할 수 있게 되기 때문입니다.

순환 참조는 어떻게 끊나요? 즉, 위 그림의 속이 빈 삼각형 화살표는 언어에서 어떻게 표현될까요? 상속으로 표현합니다. 자바로 치자면 extends 혹은 implements가 되겠죠. 대표적 사례는? Observer Pattern. (다시 보니 위 그림은 별로 예쁘지 않군요. 대충 예쁜 의존성 역전의 사례를 상상해주세요)

잠깐 딴소리: 아마도 GoF 패턴책이 번역된 후로, 다른 커뮤니티는 모르겠고, 자바 개발자들 사이에서 extends는 꼬지고 implements는 좋은거라는 미신이 널리 퍼졌죠. 좀 과장하자면 구현 상속은 delegation(and/or composition)으로 대체하고 오직 타입 상속이 쵝오, 뭐 이런 얘기인데 “extends == 구현 상속”, “implements == 타입 상속”이라는 잘못된 공식이 오해의 원인이 아니었을까 추측해봅니다. 자바의 경우 “extends == 구현 상속+타입 상속”이라고 해야 맞습니다. 즉, implements이건 extends이건 타입 상속은 일어나는거죠. 단 extends를 했을 때는 구현 상속이 따라오게 되어 있는데 이 때의 문제를 잘 인지하고 해결할 수 있으면 그냥 쓰면 되는 것이죠.

이를테면 blackbox reuse vs. whitebox reuse 문제 같은 것이 있는데, 애초에 public/published 구분 잘 하고, protected 따위 안쓰고 메서드는 몽땅 public, 필드는 몽땅 private 같은 몇 가지 원칙들만 잘 지키면 문제의 소지가 크게 줄어듭니다.

다시 본론으로 돌아와서 지금까지의 얘기를 정리해보자면 이렇습니다:

1. OOP는 구조적 프로그래밍의 selection(if/switch)을 서브타입 다형성으로 대체합니다.
2. if를 서브타입 다형성으로 대체하면 하위 계층 뿐 아니라 상위 계층 까지도 더 잘 모듈화할 수 있습니다.
3. 이러한 생각을 표현하는 말이 의존성 역전(DI) 입니다.

 

5. OOP의 나머지 개념들은 뭔가?

그럼 캡슐화(encapulation), 정보은닉(information hiding)은 안중요한가요? 중요합니다. 다만 OOP와 별 관련 없이 원래 있던 개념들입니다.

 

6. if는 다 잡아 없애야 진정한 OOP인가?

if 뿐만 아니라 switch도 다 없애야 진정한 OOP라능. 농담입니다. --;

두 가지를 이야기할 수 있겠습니다. 첫째, 진정한 OOP 아무 짝에도 쓸모 없습니다. 그런거 추구하지 마세요. 둘째, 상위 계층의 모듈화를 저해하는 if만 제거하세요. 다른 말로 바꿔서 표현하자면, 도메인 로직을 서술하기 위한 if는 남겨두세요.

 

7. OOP에 대하여 지금 서술한 관점이 킹왕짱인가?

저는 그렇다고 생각합니다. 하지만 “제일 좋은 관점”이랑 “완전한 관점”은 다른 것이죠. 제일 좋은 관점이라고 믿고 있기는 하지만 이 관점만으로 밀기엔 불충분하고 생각도 덜 다듬어진 것 같습니다. 따라서 여러 관점을 머리 속에 담아두고 그때그때 가져다 쓰는 식으로 생각하고 있습니다.