💡 컴포넌트 결합

<aside> 💡 컴포넌트 사이의 관계를 설명하며, 개발 가능성과 논리적 설계 사이의 균형을 다루는 원칙을 서술

</aside>

ADP : Acyclic Dependencies Principle

• ADP, 의존성 비순환 원칙이란

  <aside> 💡 컴포넌트 의존성 그래프에 순환 ( cycle )이 있어서는 안된다는 원칙

  </aside>

  • 내가 작업 하는 코드가, 특정 코드에 의존 되어 있다면 내가 코드를 수정하지 않아도 의존하고 있는 코드가 수정되면 내 코드가 돌아가지 않는다.

  • 이러한 경우를 책에선 숙취 증후군 이라고 표기하고 있음

  • 이런 숙취 증후군을 피하기 위해 주 단위 빌드 / 의존성 비순환 원칙 을 제시하고 있음

  • 주단위 빌드

    • 중간 규모의 프로젝트에서 흔하게 사용 됨
    • 5일 중 4일간은 서로 신경쓰지 않고 개발하고, 나머지 하루를 merging 하는데 소모
    • 장점
      • 4일 동안 개발 할 때엔 다른 의존성을 전혀 신경쓰지 않아도 됨
    • 단점
      • 통합에 드는 시간이 점점 늘어날 가능성이 매우 매우 높음
      • 하루 걸리던것이 일주일 걸리는 건 순식간이며 효율성이 매우 저하 될 수 있음

  • 의존성 비순환 원칙

    • 컴포넌트 단위 개발
      • 개발 환경을 릴리즈 가능한 컴포넌트 단위로 분리
      • 컴포넌트는 개별 개발자 / 개발 팀이 책임 지는 개발 작업 단위가 됨
      • 해당 컴포넌트를 릴리즈 하여 다른 개발자가 사용 할 수 있도록 만듬
      • 릴리즈 번호가 부여 되어 있기 때문에, 다른팀에서 사용하는 컴포넌트는 사용하고 있는 컴포넌트 릴리즈 번호에 의존 되어 있음
      • 즉, 다른 팀이 릴리즈를 새로 했더라도 이전 버전을 사용 하며 다른 팀의 컴포넌트에 문제가 있더라도 우리 팀의 컴포넌트에서는 문제 회피를 할 수 있음
      • 따라서 어떤 팀도 다른 팀에 좌우되지 않으며, 특정 컴포넌트가 변경 되더라도 다른 팀에 즉각 영향을 줄 수 없음
      • 통합은 작고 점진적으로 이루어 짐
    • 컴포넌트 단위 개발을 진행하기 위해선, 반드시 컴포넌트 사이의 의존성 구조를 관리 해 주어야 함
      • 순환이 생길 시 숙취 증후군이 생기기 때문에 의존성 구조에 순환이 있어서는 안됨
    • 의존성 그래프 예시

      • 순환 의존이 없는 의존성 그래프

        

        출처 : https://icarus8050.tistory.com/47

        • Main 컴포넌트
          • 위 그래프를 보면, Main 컴포넌트는 View / Controllers / Authorizer / Presenter / Database에 의존 하고 있음
          • 또, Main 컴포넌트는 Main 컴포넌트에 의존하고 있는 컴포넌트는 없기 때문에, Main 컴포넌트가 새로 릴리즈 되더라도 영향을 받는 컴포넌트는 하나도 없음
          • 즉, Main을 새로 릴리즈 함으로써 미치게 되는 충격은 매우 적은 상황
        • Presenter 컴포넌트
          • Presenter 컴포넌트를 만드는 개발자는, Interactors와 Entities를 빌드해서 Presenter 자체 버전을 빌드하여 테스트 하면 됨 ( 이외의 다른 컴포넌트의 영향을 받지 않음 )
          • Presenter를 만드는 개발자가 테스트를 구축 할 때, 비교적 적은 노력이 드는 것 → 고려할 변수가 적다는 것
        • 시스템 전체를 릴리즈 해야 한다면, 릴리즈 절차는 상향식임 ( Entities 컴파일 / 테스트 / 릴리즈 → Database / Interactors 컴파일 / 테스트 / 릴리즈 ... → Main 컴파일 / 테스트 / 릴리즈 ... )

      • 순환 참조가 있는 의존성 그래프

        

        출처 : https://icarus8050.tistory.com/47

        • Entities가 Authorizer에 의존 하게 되었음
        • 이 경우엔, Interactors / Entities / Authorizers 가 서로 의존성을 가지게 되며 순환 의존성을 가짐
        • 이는 Entities / Authorizer / Interactors가 사실상 하나의 거대한 컴포넌트가 되어 버렸음을 의미
        • 이는 세개의 컴포넌트 중 어느 것을 개발하더라도 숙취 증후군이 생길 것
          • 세개 모두 정확하게, 동일한 릴리즈를 사용해야 하기 때문 ( 의존성이 생기기 때문 )
        • 테스트 할 때 더욱 더 심각한 문제가 생김
          • Entities 테스트를 따로 할 수 없는 상황이 생김
          • 즉, 각 컴포넌트를 따로 테스트 할 수 없게 됨
        • 컴포넌트를 어떤 순서로 빌드 해야 맞는건지 파악 할 수 없게 됨

      • Interface를 활용한 DI를 적용하여 순환 끊기

        

        출처 : https://icarus8050.tistory.com/47

        • Entities가 필요한 메서드를 제공하는 Interface를 생성
        • 이 인터페이스는 Entities에 위치시키고, Authorizer에는 이 interface를 상속 받아 실제 구현 함
        • 이렇게 하면, Entities가 Authorizer에 의존하던 의존성을 Entities에 가져 올 수 있으며 이를 통해 순환을 끊을 수 있음

      • 순환 의존성을 끊어 줄 새로운 컴포넌트 생성

        

        출처 : https://icarus8050.tistory.com/47

        • 두 컴포넌트가 모두 의존하는 클래스들을 새로운 컴포넌트 ( Permissions )로 이동 시킴
        • 이를 통해 순환 의존성을 끊을 수 있음

    흐트러짐 ( Jitters )과 하향식 설계

    • 위의 순환 의존성을 끊는 과정을 살펴보면, 요구사항이 변경될 시 컴포넌트 구조도 변경 될 수 있음을 확인 할 수 있었음
    • 즉, 프로젝트가 커짐에 따라 새로운 컴포넌트를 생성하거나 의존성 구조가 더 커질 수 도 있음을 암시
    • 이를 살펴보면, 컴포넌트 구조는 하향식으로 설계 될 수 없음
    • 즉, 컴포넌트는 시스템에서 가장 먼저 설계 할 수 있는 대상이 아니며, 시스템이 성장하고 변경 될 때 함께 변경 / 진화 됨
    • 컴포넌트 의존성 다이어그램은, 응용 프로그램의 기능을 서술하는 일과는 전혀 관련이 없으며 빌드 가능성 / 유지 보수성을 보여주는 지도와 같음
    • 따라서 컴포넌트 구조는 프로젝트 초기에 설계 할 수 없음
    • 프로젝트가 커짐에 따라 재사용 가능한 요소를 만드는 일에 관심을 가지게 됨

  SDP : Stable Dependencies Principles

  • SDP, 안정된 의존성 원칙 이란

    <aside> 💡 안정성의 방향으로 의존하라. 즉 더 안정된 쪽에 의존하라

    </aside>

    • 변경이 쉽지 않은 컴포넌트가, 변동이 예상되는 컴포넌트에 의존하게 만들어서는 절대로 안됨
    • 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않게 만들어야 함

  • 안정성 ( Stability )

    • 변경을 만들기 위해 필요한 작업량에 관련 된 개념

      • 필요한 작업량이 많을수록 안정성이 높다고 할 수 있음

    • 동전을 옆으로 세웠을 때, 쓰러지지 않았다고 해서 안정적이라고 표현하지는 않음

      • 툭 하고 치면 쓰러지기 때문에 안정성이 낮음

    • 컴포넌트 안쪽으로 들어오는 의존성이 많아지면 ( 해당 컴포넌트를 많이 참조 하는 다른 컴포넌트가 많다면 ) 상당히 안정적이라고 할 수 있음

      

      출처 : https://icarus8050.tistory.com/47

      • X는 세 컴포넌트를 책임 지고 있음
      • X는 어디에도 의존하지 않으므로 변경되도록 만드는 외적인 영향이 전혀 없음 → 독립적임

    • 컴포넌트 밖으로 나가는 의존성이 많아지면 ( 해당 컴포넌트를 참조하는 다른 컴포넌트가 없다면 ) 상당히 불안정 적이라고 할 수 있음

      

      출처 : https://icarus8050.tistory.com/47

      • 어떤 컴포넌트도 Y에 의존하고 있지 않으므로 Y는 책임성이 없다고 할 수 있음
      • Y는 세개의 컴포넌트에 의존 하고 있으므로, 변경이 발생 할 수 있는 외부 요인이 세가지 → 의존적임

    • 안정성 지표

  SAP : Stable Abstractions Principle

  • SAP, 안정된 추상화 원칙이란
  • SAP에서는, 안정성과 추상화 정도 사이의 관계를 정의 하고 있음
  • 안정된 컴포넌트는 추상 컴포넌트여야 한다고 말함
  • 불안정한 컴포넌트는 반드시 구체 컴포넌트여야 한다고 말함
  • 따라서, 안정적인 컴포넌트라면 반드시 인터페이스 / 추상 클래스로 구성되어 쉽게 확장 할 수 있어야 한다고 말함
  • 추상화 정도
  • 주계열