[책 정리] 5장. 객체 지향 프로그래밍 - Clean Architecture

-

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

캡슐화?

-

OO 프로그래밍은 프로그래머가 충분히 올바르게 행동함으로써 캡슐화된 데이터를 우회해서 사용하지 않을 거라는 믿음을 기반으로 한다.

OO 를 제공한다고 주장한 언어들이 실제로는 C언어에서 누렸던 완벽한 캡슐화를 약화시켜 온 것은 틀림없다.

상속?

-

OO 언어가 더 나은 캡슐화를 제공하지는 못했지만, 상속만큼은 OO 언어가 확실히 제공했다.

하지만 상속이란 단순히 어떤 변수와 함수를 하나의 유효 범위로 묶어서 재정의하는 일에 불과하다.

OO 언어가 완전히 새로운 개념을 만들지는 못했지만, 데이터 구조에 가면을 씌우는 일을 상당히 편리한 방식으로 제공했다고 볼 수는 있다.

다형성?

-

함수를 가리키는 포인터를 응용한 것이 다형성이다.

OO 언어는 다형성을 제공하지는 못했지만, 다형성을 좀 더 안전하고 더욱 편리하게 사용할 수 있게 해준다.

함수에 대한 포인터를 직접 사용하여 다형적 행위를 만드는 방식은 위험하다. (수동으로 따라야 하는 관례가 많았다.)

* 다형성이 가진 힘

-

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

그럼에도 대다수의 프로그래머는 함수 포인터를 사용하는 위험을 수반하지 않기 위해 이러한 개념을 확장하여 적용하지 않았다.

그러나 OO 의 등장으로 언제 어디서든 플러그인 아키텍처를 적용할 수 있게 되었다.

* 의존성 역전

-

main 함수가 고수준 함수를 호출하려면 고수준 함수가 포함된 모듈의 이름을 지정해야만 한다.

이러한 제약 조건으로 인해 제어흐름은 시스템의 행위에 따라 결정되며, 소스 코드 의존성은 제어흐름에 따라 결정된다.

하지만 다형성이 끼어들면 이야기는 달라진다.

인터페이스와 이를 구현하는 클래스 사이의 소스 코드 의존성이 제어흐름과 반대가 된다. 이를 의존성 역전 (dependency inversion)이라고 부른다.

OO 언어가 다형성을 안전하고 편리하게 제공한다는 사실은 소스 코드 의존성을 어디에서든 역전시킬 수 있다는 뜻이기도 하다.

이런 접근법을 사용하면 OO 언어로 개발된 시스템을 다루는 소프트웨어 아키텍트는 시스템의 소스 코드 의존성 전부에 대해 방향을 결정할 수 있는 절대적 권한을 갖는다.

즉, 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않는다.

호출하는 모듈이든 아니면 호출 받는 모듈이든 관계없이 소프트웨어 아키텍트는 소스 코드 의존성을 원하는 방향으로 설정할 수 있다.

이것이 OO 가 제공하는 힘이다.

그리고 이것이 OO 가 지향하는 것이다!

-

UI, Business Rules, Database 세 가지로 분리된 컴포넌트 중..

Business Rules 는 UI 와 데이터베이스와는 독립적으로 배포할 수 있다.

UI 나 DB 에서 발생한 변경사항은 업무 규칙에 일절 영향을 미치지 않으며, 이들 컴포넌트는 개별적이며 독립적으로 배포 가능하다.

이것이 배포 독립성(independent deployability)이다.

-

시스템의 모듈을 독립적으로 배포할 수 있게 되면, 서로 다른 팀에서 각 모듈을 독립적으로 개발할 수 있다.

그리고 이것이 개발 독립성(independent developability)이다.

-

소프트웨어 아키텍트 관점에서 정답은 명백하다.

OO란 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력이다.

OO를 사용하면 아키텍트는 플러그인 아키텍처를 구성할 수 있고, 이를 통해 고수준의 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장할 수 있다.

저수준의 세부사항은 중요도가 낮은 플러그인 모듈로 만들 수 있고, 고수준의 정책을 포함하는 모듈과는 독립적으로 개발하고 배포할 수 있다.