클린 아키텍처 - 5장. 객체지향 프로그래밍 Object-Oriented Programming

■ 5장 객체지향 프로그래밍 Object-Oriented Programming

​

OO의 본질을 설명하기 위해 3가지 특성을 살펴보자.

​

1. 캡슐화

사실 캡슐화는 C 언어에서 완벽하게 구현되었었고 오히려 C++에서 완벽한 캡슐화가 깨지게 되었다. 클래스의 멤버변수를 클래스 헤더 부분에 선언하도록 함으로써 해당 헤더파일(xxxx.h 같은)을 사용하는 측에서 멤버변수의 존재를 알 수 있기 때문이다. 따라서 OO가 강력한 캡슐화에 의존한다는 정의는 받아들이기 어렵다.

​

2. 상속

OO 언어가 있기 전에도 상속을 흉내낼 수는 있었지만 OO 언어에서 확실히 상속을 편리하게 만든 건 사실이다. 게다가 다중 상속은 기존에 훨씬 어려웠다. 그래서 OO에 있어 캡슐화에 대해서는 0점, 상속에 대해서는 0.5점을 주겠다.

​

3. 다형성

OO 이전에도 물론 다형성을 표현할 수 있었다. C의 STDIN/STDOUT 등이 그 예이다. 입력 장치가 실제 어떤 것이든 상관없이 C 언어에는 getchar()로 STDIN에서 문자를 읽어들이며 FILE 데이터 구조의 read 포인터가 가리키는 함수를 호출한다. C++에서는 클래스의 모든 가상함수가 vtable이라는 테이블에 포인터를 가지고 있다.

​

결국 다형성은 함수를 가리키는 포인터를 응용한 것이다. 하지만 함수 포인터를 사용하는 것은 매우 위험한 일이고 버그를 찾는 것도 어려운데 OO 언어가 이런 어려움을 없애주었고 다형성을 대수롭지 않은 것으로 만들어 주었다.

​

 

728x90

 

 

가령 복사 프로그램이 있다고 할 때, 입력장치를 필기체 인식장치에서 음성합성장치로 바꾼다고 해도 프로그램을 변경하거나 재컴파일할 필요가 없다. 입출력 드라이버가 복사 프로그램의 플러그인이 되는 것이다. OO의 등장으로 쉽게 플러그인 아키텍처를 적용할 수 있게 되었다.

​

다형성이 없는 소프트웨어에서는 아래 그림처럼 제어의 흐름이 소스코드 의존성과 같은 방향을 따르게 된다. 모든 호출함수는 피호출함수가 포함된 모듈의 이름을 명시적으로 지정해야 한다.

​

​

하지만 다형성을 적용해서 아래 그림처럼 소스코드 의존성(상속관계)과 제어흐름을 반대로 가져갈 수 있다. 이것이 의존성 역전 dependency inversion 이라는 중요한 개념이다. 호출하는 모듈이든 호출받는 모듈이든 관계없이 소스코드 의존성을 아키텍트가 원하는 대로 설정할 수 있다.

​

​

이것이 OO가 제공하는 힘이고 OO가 지향하는 것이다. 이를 통해 무엇을 할 수 있냐면 업무규칙이 데이터베이스와 UI에 의존하지 않고 소스코드 의존성을 반대로 하여 데이터베이스와 UI가 업무규칙에 의존하게 만들 수 있다는 것이다.

​

​

즉 UI와 데이터베이스가 업무규칙의 플러그인인이 되는 것이다. 플러그인이라는 것은 업무규칙을 변경하지 않고 다른 것으로 교체가 가능하다는 말이다. 이는 배포 독립성을 보장한다. 그리하면 서로 다른 팀에서 모듈을 독립적으로 개발할 수 있어 개발 독립성도 보장된다.

​

결론적으로 아키텍트 관점에서 OO는 다형성을 이용하여 모든 소스코드 의존성의 제어 권한을 획득하는 능력이라고 할 수 있다.

​

​

<6장에서 계속>

​