Clean Architecture_2부 정리

4장. 구조적 프로그래밍

데이크스트라:

• goto문장이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 되는 경우가 있다는 사실 발견
• 모듈을 분해할 수 없으면 분할 정복 접근법 사용 불가
• goto문의 좋은 사용 방식은 if, then, else, do/while 과 같은 분기와 반복이라는 단순한 제어 구조에 해당한다는 사실 발견
• 이러한 종류의 제어구조만 사용한다면 증명 가능한단위로 모듈을 재귀적으로 세분화 하는 것이 가능

뵘과 야코피니:

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

→ 모듈을 증명가능하게 하는 바로 그 제어 구조가 모든 프로그램을 만들 수 있는 제어구조의 최소 집합과 동일 → 구조적 프로그래밍 탄생

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

객체 지향 언어의 필수 요소

• 캡슐화
  • 객체지향 언어는 데이터와 함수를 쉽고 효과적으로 캡슐화라는 방법을 제공
  • 데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선을 그을 수 있음
  • 구분선 밖에서 데이터는 은닉되고, 일부 함수만이 외부에 노출
• 상속
  • 어떤 변수와 함수를 하나의 유효 범위로 묶어서 재정의 하는 일
• 다형성
  • 함수를 가리키는 포인터를 응용한것
  • 제어 흐름을 간접적으로 전환하는 규칙을 부과
  • 장점
    • 언제 어디서든 플러그인 아키텍처를 적용할 수 있게됨

의존성 역전

• 모든 호출 함수는 피호출 함수가 포함된 모듈의 이름을 명시적으로 지정해야함.
  • 제어 흐름은 시스템의 행위에 따라 결정되며, 소스 코드 의존성은 제어흐름에 따라 결정됨
• 다형성 사용시
  • 소스코드 의존성은 소스 코드 사이에 인터페이스를 추가함으로 방향을 역전 시킬수 있음
    • 객체지향 언어로 개발된 시스템을 다루는 소프트웨어 아키텍트는 시스템의 소스 코드 의존성 전부에 대해 방향을 결정할 수 있는 절대적인 권한을 얻음
      • 소스 코드 의존성이 제어 흐름의 방향과 일치도도록 제한되지 않는다.
        • ex) 업무 규칙이 데이터베이스와 사용자 인터페이스에 의존하는 대신, 시스템의 소스 코드 의존성을 반대로 배치하여 데이터베이스와 UI가 업무 규칙에 의존하도록 만들 수 있음
          • UI와 데이터베이스가 업무 규칙의 플로그인
            • 업무 규칙의 소스 코드에서는 UI나 데이터베이스를 호출하지 않음
              • 업무 규칙, UI, 데이터베이스는 세가지로 분리된 컴포넌트 또는 배포 가능한 단위로 컴파일 할 수 있고, 이 배포 단위들의 의존성 역시 소스 코드 사이의 의존성과 같다.
                • 업무 규직을 포함하는 컴포넌트는 UI와 데이터베이스를 포함하는 컴포넌트에 의존하지 않는다.
                  • 업무 규칙을 UI와 데이터베이스와는 독립적으로 배포 가능
                    • 특정 컴포넌트의 소스 코드가 변경되면 해당 코드가 포함된 컴포넌트만 다시 배포하면 된다.(배포 독립성)
    • 시스템의 모듈을 독립적으로 배포할 수 있게 되면 서로 다른 팀에서 각 모듈을 독립적으로 개발 가능 (개발 독립성)

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

• 아키텍트는 플러그인 아키텍처를 구성할 수 있고, 이를 통해 고수준의 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장 가능
• 저수준의 세부사항은 중요도가 낮은 플러그인 모듈로 만들수 있고, 고수준의 정책을 포함하는 몯률과는 독립적으로 개발하고 배포할 수 있다.

6장. 함수형 프로그래밍

• 핵심 기반 : 람다 계산법
• 함수형 언어에서는 변수는 변경되지 않음
  • 경합조건, 교착상태조건, 동시 업데이트 문제가 모두 가변 변수로 인해 발생
    • 변수가 갱신되지 않으면 문제 발생 안함

가변성의 분리

• 불변성과 관련하여 가장 주요한 타협 중 하나는 애플리케이션 또는 애플리케이션 내부의 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리하는 일
• 불변 컴포넌트
  • 순수하게 함수형 방식으로만 작업이 처리
  • 어떤 가변 변수도 사용되지 않음
  • 불변 컴포넌트는 변수의 상태를 변경할 수 있는, 즉 순수 함수형 컴포넌트가 아닌 하나 이상의 다른 컴포넌트와 서로 통신
  • 상태 변경은 컴포넌트를 갖가지 동시성 문제에 노출
    • 트랜잭션 메모리와 같은 실천법을 사용하여 동시 업데이트와 경합 조건 문제로부터 가변 변수를 보호
      • 트랜젝션 메모리는 데이터베이스가 디스크의 레코드를 다루는 방식과 동일한 방식으로 메모리의 변수 처리
        • 트랜잭션을 사용하거나 또는 재시도 기법을 통해 변수를 보호
• 애플리케이션을 제대로 구조화 하려면 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야함
  • 이렇게 분리하려면 가변 변수들을 보호하는 적절한 수단을 동원해 뒷받침 해야함
• 가능한 많은 처리를 불변 컴포넌트로 옮겨야하고, 가변 컴포넌트에서는 가능한 많은 코드를 빼야함