함수형 프로그램 컴포넌트 정의 응집도 결합도 20221108

함수형 프로그램
  - 람다 계산법
  - 함수형 언어에서는 변수는 변경되지 않는다
 
  * 경합조건, 교착상태, 동시 업데이트 문제는 모두 가변 변수에서 발생

  * 가변성 분리
     - 애플리케이션 내부의 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리

  * 이벤트 소싱
     - 데이터 저장소에 CRUD 가 아닌 CR만 수행


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

  순차,분기,반복,참조로 구성


컴포넌트
  - 컴포넌트는 배포 단위
  - 시스템의 구성요소로 배포할 수 있는 가장 작은 단위
  - 자바는 jar, 루비는 gem, 닷넷은 dll 등
  - 컴파일형 언어에서의 컴포넌트는 바이너리 파일의 결합체
  - 모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자
  - 반드시 독립적으로 배포가능

  * 재배치성
    지능적인 로더를 사용해서 메모리에 재배치 할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정
    재배치가 가능한 바이너리
    외부정의를 로드할 위치가 정해 지기만 하면 외부 참조를 외부 정의에 링크 시킬 수 있게 된다. (링킹로더 탄생)

 * 링커
    링커는 링크가 완료된 재배치 코드를 만들어 주었고 로더의 로딩 과정이 아주 빨라졌다.
    로드는 빨리지었지만 컴파일-링크 시간은 여전히 병목구간

================================================================================

컴포넌트 응집도
  REP (Reuse,Release Equivalence Principle) : 재사용/릴리스 등가 원칙
  CCP(Common Closure Principle)             : 공통 폐쇄의 원칙
  CRP(Common Reuse Principle)               : 공통 재사용 원칙

  REP : 재사용/릴리스 등가 원칙
  - 재사용 단위는 릴리즈 단위와 같다
  - 컴포넌트가 릴리즈 절차를 통해 추적 관리 되지 않거나 릴리즈 번호가 부여되지 않은다면 해당
    컴포넌트를 재사용 하고 싶어도 할 수 없고 하지도 않을 것인다.
  - 릴리즈 번호 관리

  CCP: 공통 폐쇄 원칙
   - 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶음
   - 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리
   - SRP 처럼 CCP도 단일 컴포넌트는 변경의 이유가 여러개 있어서는 안된다.
   - CCP는 OCP(확장에는 열러있고 변경에는 닫혀 있음)에서 얻은 교훈을 확대 적용

    * SRP와 CCP의 유사성
      - CCP는 컴포넌트 수준의 SRP(서로 다른 이유로 변경되는 클래스를 서로 다른 클래스로 분리)
      - 서로 다른 이유로 변경되는 클래스를 서로 다른 컴포넌트로 분리

  CRP:공통 재사용의 원칙
   - 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라
   - 공통 재사용 원칙도 클래스와 모듈을 어느 컴포넌트에 위치 시킬지 결정할 때 되움이 되는 원칙
   - 같이 재사용 되는 경향이 있는 클래스와 모듈은 같은 컴포너트에 포함되어야 한다.
   - 각 컴포넌트에 어떤 클래스를 포함 시켜야 하는지 설명
   - 동일한 컴포넌트로 묶어서는 안되는 클래스가 무엇인지 설명
   - 강하게 결합되지 않는 클래스들을 동일한 컴포넌트에 위치 시키지 마라

     * ISP 와의 관계
       CRP는 인터페이스 분리 원칙(ISP)의 포괄적인 버전
       ISP는 사용하지 않는 메서드가 있는 클래스에 의존하지 마라
       CRP는 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라(필요하지 않는 것에 의존하지 마라)


 REP와 CCP는 포함의 원칙 이며 컴포넌트를 크게 만드는 기능
 CRP는 배제 원칙이며 컴포넌트를 작게 만드는 기능


================================================================================

컴포넌트 결합도
 
  ADP : 의존성 비순환 원칙
   - 컴포넌트 의존성 그래프에 순환이 있어서는 안된다.
   - 숙취 증후군 : 내가 의존하고 있는 무언가가 수정이 되어서 작동하던 프로그램이 동작하지 않는다
      해결책으로는 주단위 빌드, 의존성 비순환 원칙

      주단위 빌드
        1주중 4일은 개발 하루는 통합과 관련된 일 진행

      순환 의존성 제거
        개발환경을 일리즈 가능한 컴포넌트 단위로 분리
        컴포넌는 개별 개발자 또는 단일 개발팀이 책일 질 수 있는 단위
        개발자 자신만의 공간에서 컴포넌트 지속 수정 나머지 개발자 릴리즈된 버전을 사용
        새 버전 사용여부를 다른 개발팀에서 선택가능 컴포넌트가 변경되어도 즉각적인 영향을 주지 않는다


      * 순환끊기
      - 의존성 역전 원칙을 적용

      * 컴포넌트 구조는 하향식 설계가 될 수 없다


  SDP: 안정된 의존성 원칙
   - 안정성의 방향으로 의존하라
   - 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들어야 한다

     * 안정성
        - 컴포넌트 안쪽으로 들어오는 의존성이 많아지면 상당히 안정적이라 볼수 있다 (Fan-in)
        - 모든 나가는 라인 /  모든 연결된 라인  (= 들어오는 것 + 나가는 것) 이 1보다 작으면 안정

     * 추상 컴포넌트
        - 오로지 인터페이스만을 포함하는 컴포넌트를 생성하는 방식인 추상 컴포넌트는 상당히 안정적

  SAP: 안정된 추상화 원칙
    - 컴포넌트는 안정된 정도만큼만 추상화 되어야 한다
    - OCP(개방 폐쇄 원칙)에서 안정된 상태이면서도 동시에 변경에 충분히 대응할 수 있게 유연하게 만들 수 있다.

    * 안정된 추상화 원칙
      - 안정된 추상화 원칙(Stable Abstractions Principle SAP)은 안정성(Stable)과 추상화 정도(Abstractions) 사이의 관계를 정의
      - 안정된 컴포넌트는 추상 컴포넌트여야 하며 안정성이 컴포넌트를 확장하는 일을 방해해서는 안된다

    *SAP와 SDP를 결합하면 컴포넌트에 대한 DIP과 같다.
      - SDP 에서는 의존성이 반드시 안정성의 방향으로 향해야 한다고 말하고 SDP에서는 안정성이 결과 추상화를 의미
      - 의존성은 추상화 방향으로 향하게 된다.
      - 핵심은 안정적인 컴포넌트라면 받드시 인터페이스와 추상 클래스로 구성되어 쉽게 확장 할 수 있어야 한다.

    * 추상화 정도 측정
      - NC : 컴포넌트의 클래스 개수
      - Na : 컴포넌트의 추상 크래스와 인터페이스의 개수
      - 추상화 정도 : A=Na/Nc   
      - A가 0이면 추상 클래스가 한개도 없고 A가 1이면 추상 클래스만 존재