'다형성' 검색 결과 1건

  1. 2009.07.22 OOP와 생산성 - 다형성의 문제점? (12)

Object Oriented Programmer's Productivity 를 읽고 씁니다. 글에서 주장하는 바를 간략히 요약하자면 이렇습니다:

  1. OOP 하면 동적 디스패치(dynamic dispatch, 대충 쉽게 말해서 다형성)가 가장 먼저 떠오르는데,
  2. 동적 디스패치는 코드를 읽기 어렵게 만들기 때문에 위험하고, OOP는 이를 장려하기 때문에 결국 문제가 된다.
  3. OOP의 장점은 다형성에 있다기 보다는 캡슐화에 있는데, 그 이유는 구조적 프로그래밍에 비해 전역 변수를 덜 쓰도록 장려하기 때문이다.

1)번은 동의하는 바이고(OOP란 조건문을 줄이는 것 참고), 2,3번에는 동의하지 않습니다. 하나씩 따져보면


1. "동적 디스패치는 코드를 읽기 어렵게 만든다"는 주장에 대해

이 문제는 정적인 프로그램(즉 소스 코드)과 동적인 프로세스(dynamic process) 사이의 간극이 넓어지면 프로그램을 분석하기가 어려워진다는 문제의 한 가지 사례인데요(혹시 부연 설명이 필요하시면 Goto 문과 AOP, 그리고 Subtext 참고), 간단히 말해서 코드를 읽다 말고 실제로 무엇이 실행되는지 파볼(drill-down) 필요가 생기지만 않는다면 문제될 것이 없습니다. 그러니깐, 설계를 잘 하면 된다는 말입니다.

이 맥락에서 올바른 설계란... 대충 중요한 것을 꼽자면 첫째, 일반화(generalization)가 올바르게 되어 있고(즉, LSP 혹은 contract - design by contract에서 말하는 - 를 잘 지키고 있고), 둘째, 클래스 및 인스턴스의 이름이 적절히 지어져 있으며(intention revealing), 3) 해당 코드의 주변부와 추상화의 수준(level of abstraction)에 일관성이 있는 것을 말합니다.

이런 상황이라면 특정 오퍼레이션(operation)에 대한 구현 코드(method)의 내용이 무엇인지 궁금해할 일이 없습니다.

사실 동적 디스패치가 코드 읽기를 어렵게 만든다는 식의 문제 제기라면 글쓴이가 좋아하는 Haskell(함수형 언어의 일종입니다)도 문제가 되는데요, 왜냐하면 higher-order programming이라는 것 자체가 함수를 인자로 넘기거나 함수를 반환값으로 받아서 쓰는 것이고 이렇게 되면 결국 늘상 일어나는 일이 동적 디스패치거든요.


2. "OOP의 장점은 다형성에 있다기 보다는 캡슐화에 있는데, 그 이유는 구조적 프로그래밍에 비해 전역 변수를 덜 쓰도록 장려하기 때문이다"는 주장에 대해

다형성은 문제이고 캡슐화가 진정한 장점이라는 얘긴데 그럴거면 OOP라는 것이 있을 이유가 없고 그냥 모듈화 프로그래밍(modular programming)이라는 말이면 충분하겠죠.

캡슐화라는 것은 구조적 프로그래밍이나 객체지향 프로그래밍과 직교적(orthogonal)인 개념으로 보는 것이 자연스럽습니다. 대부분의 구조적 언어는 모듈화 프로그래밍을 지원하고 있고, 객체지향 언어 또한 마찬가지라서 프로그래머가 어떻게 잘 쓰느냐에 따라 캡슐화가 잘 될 수도 있고 아닐 수도 있습니다.

이를테면 코드와 데이터를 묶으려면 구조체에 함수 포인터 넣어두고, 각 함수는 첫번째 인자로 자신이 속한 구조체를 받으면(python의 self와 유사) 되는 것이죠. 구조체가 없거나 함수 포인터가 없는 언어(구조적 언어의 요건은 모두 갖추었으나 함수 포인터가 없는 언어로는... 이를테면 QBasic이나 QuickBasic이 그렇습니다)라면 prefix나 postfix로 그룹핑을 하는 관습을 만들면 그만입니다(실제로 널리 쓰이던 관습입니다. namespace 개념이 없거나 약했거든요).

뭐 구현 가능성에 대해서는 그렇다치고, 구조적 프로그래밍에 비해 객체지향 프로그래밍이 캡슐화를 좀 더 강조하고 있다는 주장도 있는데 이 또한 별 설득력이 없습니다(시스템을 모듈로 나누는 기준에 대하여 참고. 추측컨데 저자가 구조적 프로그래밍을 충분히 경험해보지 못한 것이 아닌가 싶습니다).

저자는 캡슐화의 단적인 예로 전역 변수(global variable) 문제를 들고 있는데 이에 대해서는 의존의 자기유사성을 참고하시면 좋겠습니다. 전역 변수 문제라는 것은 사실 스케일의 차이만 있을 뿐 일반적인 의존성 문제의 하나이고, 객체지향 프로그래밍을 하건 구조적 프로그래밍을 하건, 전역 변수가 있건 없건 항상 존재하는 문제이고 신경 써야 하는 문제입니다.

게다가 자바처럼 전역 변수라는 개념이 아예 없는 언어에서도 전역 변수 문제는 여전히 존재할 수 있고(전역 변수가 없지만 전역 변수 문제는 존재한다는 표현이 좀 이상하지만 뭐 맞는 말입니다) 실제로 많은 개발자들이 이 문제로 허덕이고 있습니다. 이에 대해서는 모드 없는 소스코드 중 "모드와 숨은 변수들" 섹션 참고하시기 바랍니다.

OOP 덕에 전역 변수가 많이 줄었다는 것은 아쉽게도 착각입니다. 일례로 Singleton Pattern을 보세요. 이건 사용이 장려되고 있는 (디자인 패턴이라는 탈을 쓰고 나타난) 전역 변수 아닌가요?


3. 결론 및 부연

첫째, 동적 디스패치가 일어나는 부분이 읽기 어렵다면 그건 설계/코딩을 잘못했기 때문입니다. 아무리 좋은 도구라도 쓰는 사람이 잘 쓰지 못하면 문제가 생기는거죠.

둘째, 캡슐화라는 것은 그걸 ADT(Abstract Data Type)라고 표현했건, 모듈이라고 표현했건 간에 객체지향프로그래밍과 무관하게 예전부터 있어 왔던 개념과 별 다른 점이 없습니다. 애초에 모든 (쓸모있는) 프로그래밍 언어는 조합(combination)과 추상화(abstraction) 요소를 갖추고 있는데(Structure and Interpretation of Computer Programs), 객체지향언어도 예외는 아닌 것이죠.

저작자 표시
신고
< Newer     Older >

티스토리 툴바