[클린 아키텍처] 2부_ 벽돌부터 시작하기: 프로그래밍 패러다임

로버트 C 마틴 - 클린 아키텍처 읽은 내용 정리 글.

: 2부_ 벽돌부터 시작하기: 프로그래밍 패러다임

 

3장. 패러다임 개요

세 가지 패러다임

• 구조적 프로그래밍
  • 최초로 적용된 패러다임 (하지만 최초로 만들어진 패러다임은 아님)
  • 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.
• 객체지향 프로그래밍
  • 알골 언어의 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견하였고, 이러한 함수가 클래스의 생성자가 되었고, 지역 변수는 인스턴스 변수, 그리고 중첩 함수는 메서드가 되었다.
  • 함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장하게 되었다.
  • 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.
• 함수형 프로그래밍
  • 가장 먼저 만들어진 패러다임으로 컴퓨터 프로그래밍 자체보다 먼저 등장.
  • 대다수의 함수형 언어가 변수 값을 변경할 수 있는 방법을 제공하기는 하지만, 까다로운 조건에서만 가능하다.
  • 함수형 프로그래밍은 할당문에 대해 규칙을 부과한다.

생각 & 결론

각 패러다임은 프로그러머에게 권한을 발탁하고, 새로운 권한을 부여하지 않는다.

각 패러다임은 부정적인 의도를 가지는 일종의 축적인 규칙을 부과한다.

즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안 되는지를 말해준다.

 

4장. 구조적프로그래밍

프로그래머는 프로그래밍을 잘하지 못한다는 사실, 모든 프로그램은 설령 단순할지라도 인간의 두뇌로 감당하기에는 너무 많은 세부사항을 담고 있다.

 

현재의 우리 모두는 구조적 프로그래머이며, 여기에는 선택의 여지가 없다. 제어 흐름을 아무 제약 없이 직접 전활할 수 있는 선택권 자체를 언어에서 제공하지 않기 때문이다.

 

테스트
데이크스트라는 "테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다"고 말한 적이 있다. 다시 말해 프로그램이 잘못되었음을 테스트를 통해 증명할 수는 있지만, 프로그램이 맞다고 증명할 수는 없다.

 

소프트웨어는 과학과 같다.
최선을 다하더라도 올바르지 않음을 증명하는 데 실패함으로써 올바름을 보여주기 때문이다.

결론
가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.
소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.
이를 위해 구조적 프로그래밍과 유사한 제한적인 규칙들을 받아들여 활용해야 한다.

 

5장. 객체 지향 프로그래밍

캡슐화?

데이터는 은닉되고, 일부 함수만이 외부에 노출된다.

 

상속?

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

 

다형성?

복사 프로그램을 예로 들어보자. 새로운 입출력 장치가 생긴다면 프로그램에는 어떤 변화가 생기는가?

필기체 인식 장치로부터 데이터를 읽어서 합성 장치로 복사할 때도 이 프로그램을 사용해야 한다고 해보자.

이 새로운 장비에서도 복사 프로그램이 동작하도록 만들려면 어떻게 수정해야 하는가?

- 아무런 변경도 필요치 않다! 그 이유는 복사 프로그램의 소스 코드는 입출력 드라이버의 소스 코드에 의존하지 않기 때문이다.

 

의존성 역전

시스템의 소스 코드 의존성 전부에 대해 방향을 결정할 수 있는 절대적인 권한을 갖는다.

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

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

 

결론

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

이를 통해 고수준 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장할 수 있다.

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

 

 

6장. 함수형 프로그래밍

아키텍트는 왜 변수의 가변성을 염려하는가?

- 답은 단순하다. 경합(race)조건, 교착상태(deadlock), 동시 업데이트 문제가 모두 가변 변수로 인해 발생하기 때문.

다수의 스레드와 프로세스를 사용하는 애플리케이션에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않는다.

 

애플리케이션 또는 내부의 서비스를 가변, 불변 컴포넌트로 분리

불변 컴포넌트에서는 순수하게 함수형 방식으로만 작업이 처리되며, 어떤 가변 변수도 사용되지 않는다.

불변 컴포넌트는 변수의 상태를 변경할 수 있는, 즉 순수 함수형 컴포넌트가 아닌 하나 이상의 다른 컴포넌트와 서로 통신한다.

현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다.

 

결론

요약하면

• 구조적 프로그래밍은 제어흐름의 직접적인 전환에 부과되는 규율이다.
• 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 부과되는 규율이다.
• 함수형 프로그래밍은 변수 할당에 부과되는 규율이다.

 

각 패러다임은 우리가 코드를 작성하는 방식의 형태를 한정시킨다.