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

3장 패러다임 개요

구조적 프로그래밍

무분별한 점프 -> if/then/else do/while/until 익숙한 궂로 대체

구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.

객체 지향 프로그래밍

함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지도리 수 있음을 발견

이러한 함수가 클래스의 생산자가 되었고, 지역 변수는 인스턴스 변수, 그리고 중첩 함수는 메서드가 되었다.

객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.

 

함수형 프로그래밍

불변성 : 심볼의 값이 변경되지 않는다는 개념

함수형 언어가 변수 값을 변경할 수 있는 방법을 제공하기는 하지만, 까다롭다.

함수형 프로그래밍은 할당문에 대해 규칙을 부과한다.

 

세 가지 페러다임과아키텍처의 세 가지 큰 관심사가 어떻게서로 연관되는지에 주목하자.

4장 구조적 프로그래밍

증명

모든 프로그램은 순차, 분기, 반복 이라는 세 가지 구조만으로 표현이 가능하다.

 

새로운 성명서

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

 

기능적 분해

구조적 분석, 구조적 설계 이 기법을 사용하면 프로그래머는 대규모 시스템을 모듈과 컴포넌트로 나눌 수 있고, 더 나아가 모듈과 컴포넌트는 입증할 수 있는 아주 작은 기능들로 세분화할 수 있다.

 

엄밀한 증명은 없었다.

엄밀한 증명이 고품질의 소프트웨어를 생산하기 위한 적절한 방법이라고 믿는 프로그래머는 이제 거의 없다.

수학적인 증명만이 있는 것은 아니다, 상당히 성공한 또 다른 전략으로 과학정 방법이 있다.

 

테스트

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

 

소프트웨어는 과학과 같고 따라서 반증 가능성에 의해 주도된다. 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 만들기 위해 분주히 노력해야한다.

5장 객체 지향 프로그래밍

좋은 아키텍처를 만든느 일은 객체지향 설계 우너칙을 이해하고 응용하는데서 출발한다.

OO언어는 최소한 캡슐화, 상속, 다형성 요소를 반드시 지원해야 한다고 ㅁ라한다.

 

캡슐화

데이터와 함수를 쉽고 효과적으로 캡슐화하는 방법을 OO언어가 제공

데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선을 그을 수 있다. 데이터는 은닉되고 일부 함수만이 외부에 노출된다.

OO언어에서는 각각 클래스의 private 멤버 데이터와 public 멤버 함수로 표현

 

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

 

다형성

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

포인터를 통해모든함수를 호출하는 관례를 OO언어는 없애주며, 따라서 실수할 위험이 없다.

OO는 제어흐름을 간접적으로 전환하는 규칙을 부과한다고 결론지울 수 있다.

 

다형성이 가진 힘

천공카드, 자기테이프 예시

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

 

의존성 역전

소스 코드 의존성의 방향은 반드시 제어흐름을 따르게 된다.

구현클래스와 인터페이스 사이의 소스코드 의존성이 제어흐름과는 반대인 점을 주목하자. 이는 의존성 역전이라고 부르며, 소프트웨어 아키텍트 관점에서 이러한 현상은 심오한 의미를 갖는다.

 

특정 컴포넌트와 소스코드가 변경도미ㅕㄴ, 해당 코드가 포함도니 컴포넌트만 다시 배포하면 된다. 이것이 바로 배포 독립성

배포가 독립적으로 되면 모듈을 독립적으로 개발할 수 있는데 이를 개발 독립성이라 한다.

 

6장 함수형 프로그래밍

정수를 제곱하기

자바 프로그램은 가변 변수를 사용하는데 가변 변수는 프로그램 실행 중에 상태가 변할 수 있다. 클로저 프로그램에서는 이러한 가변 변수가 전혀 없다.

함수형 언어에서 변수는 변경되지 않는다.

 

불변성과 아키텍처

경합조건, 교착상태, 동시 업데이트 모든 문제가 모두 가변 변수로 인해 발생하기 때문이다.

동시성 애플리케이션에서 마주치는 모든 문제, 가변 변수가 없다면 절대로 생기지 않는다.

 

가변성의 분리

가변 컴포넌트와 불변 컴포넌트로 분리

불변 컴포넌트에서는 순수하게 함수형 방식으로만 작업이 처리

트랜잭션 메모리와 같은 실천법을 사용하여 동시 업데이트와 경합 조건 문제로부터 가변 변수를 보호한다.

 

애플리케이션을 제대로 구조화하려면 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야 한다

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

 

이벤트 소싱

모든 트랜젝션 자체를 저장하게 되면 불변성으로 처리가 가능하지만, 무한한 저장 공간과 무한한 처리능력이 필요

영원히 동작하도록 만들 필요는 없다.

이벤트 소싱은 상태가 아닌 트랜잭션을 저장하는 전략이다. 상태가 필요해지면 단순히 상태의 시작점부터 모든 트랜잭션을 처리한다.

저장 공간과 처리 능력이 충분하면 애플리케이션이 완전한 불변셩을 갖도록 만들 수 있고, 따라서 오나전한 함수형으로 만들 수 있다.