이전 글

• 3장 패러다임 개요, 4장 구조적 프로그래밍
• 1장-설계와 아키텍처란, 2장 두가지 가치에 대한 이야기

---

5장 객체 지향 프로그래밍

좋은 아키텍처를 만드는 일은 객체 지향 ( object oriented ) 설계 원칙을 이해하고 응용하는 데서 출발한다

oo 의 본질을 설명하기 위해 세 가지 주문에 기대는 부류도 있는데, 캡슐화(encapsulation), 상속(inheriance), 다형성(polymorphism) 이 바로 그 주문이다

캡슐화

• 데이터와 함수를 쉽고 효과적으로 캡슐화 하는 방법을 oo 언어가 제공하기 때문이다
• 데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선을 그을 수 있다.

상속

다형성

• 유닉스 운영체제의 경우 모든 입출력 장치 드라이버가 다섯 가지 표준 함수를 제공할 것을 요구한다. open(열기), close(닫기), read(읽기), write(쓰기), seek(탐색) 이 바로 표준 함수들이다.
• 함수를 가리키는 포인터를 응용한 것이 다형성이다.

다형성이 가진 힘

• 플러그인 아키텍처(plugin architecture)는 입출력 장치 독립성을 지원하기 위해 만들어졌고, 등장 이후 거의 모든 운영체제에서 구현되었다.

의존성 역전

전형적인 호출 트리의 경우 main 함수가 고수준의 함수를 호출하고, 고수준의 함수는 다시 중간 수준 함수를 호출하며, 중간 수준 함수는 다시 저수준 함수를 호출한다. 이러한 호출 트리에서 소스 코드 의존성의 방향은 반드시 제어흐름(flow of control) 을 따르게 된다

의존성 역전은 예를 들어 업무 규칙이 데이터베이스와 사용자 인터페이스(UI)에 의존하는 대신, 시스템의 소스 코드 의존성을 반대로 배치하여 데이터 베이스와 UI가 업무 규칙에 의존하게 만들 수 있다.

즉 UI와 데이터베이스가 업무규칙의 플러그인 된다는 뜻이다. 다시말해 업무 규칙의 소스코드에서는 UI나 데이터베이스를 호출하지 않는다

결과적으로 업무규칙, UI, 데이터베이스는 세 가지로 분리된 컴포넌트 또는 배포 가능한 단위(jar, dll, gem ...)로 컴파일 할 수 ㅇ씨고, 이 배포 단위들의 의존성 역시 소스코드 사이의 의존성과 같다. 따라서 업무 규칙을 포함하는 컴포넌트는 UI 와 데이터베이스를 포함하는 컴포넌트에 의존하지 않는다

결론

oo 란 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력이다. oo 를 사용하면 아키텍트는 플러그인 아키텍쳐를 구성할 수 있고, 이를 통해 고수준의 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장할 수 있다.