[오브젝트] 챕터 15 - 디자인 패턴과 프레임워크

이론은 여기까지, 이제는 실전 경험을 하며 배워야 하는 단계입니다.

 

하지만 이것도 밑바닥부터 하면 효율적이지 않겠죠. 실전 경험을 하면서도 더 선배 개발자들이 이미 실무에서 반복적으로 고민하고 사용하고 효과를 본 툴들을 배우며 고민할 때가 된 것 같습니다.

 

그 시작 점은 디자인 패턴과 프레임워크인데요. 디자인 패턴은 바로 다음 부터 공부를 진행해 가면 좋을 것 같습니다.

프레임워크의 핵심 개념이 의존성 역전이라는 내용은 지금까지 제가 생각하던 안드로이드 프레임워크에 대한 개념을 명문화 한 느낌을 받았습니다. 안드로이드 컴포넌트에 한해서 내가 할 수 있는 것은 프레임워크를 공부하고 프레임워크가 특정 시점에 호출할 거라고 약속한 함수들을 구현하고 위치 시키는 것 뿐이였는데 이를 “제어 권한이 프레임워크로 역전됐다”고 표현한 게 명쾌했습니다.

---

• 도입
  • 디자인 패턴
    • 변경을 다루기 위해 반복적으로 재사용할 수 있는 설계 묶음
    • 잘 학습하면 요구 사항에서 변경의 방향과 주기를 이해하고 필요한 역할, 책임, 협력 방식을 순식간에 떠올릴 수 있게 된다.
    • 협력 템플릿 제공
  • 프레임워크
    • 애플리케이션 아키텍쳐를 구현 코드 형태로 제공
    • 확장 포인트 제공
    • 확장 가능한 코드 템플릿 제공
• 디자인 패턴과 설계 재사용
  • 패턴은 한 컨텍스트에서 유용한 동시에 다른 컨텍스트에서도 유용한 아이디어
    • 실제로 유용한지 어떻게 확인했나? → 실무를 통해서 확인 검증 된 아이디어들!
  • 패턴 분류
    • 디자인 패턴
      • 특정 정황 내에서 일반적인 설계 문제 해결
      • 협력하는 컴포넌트 사이에 반복적으로 발생하는 구조 서술
    • 아키텍쳐 패턴
      • 미리 정의된 서브시스템 제공
      • 서브시스템의 책임 정의
      • 서브시스템 사이의 관계를 조직화하는 규칙 및 가이드 제공
    • 이디엄
      • 특정 프로그래밍 언어에 국한된 하위 레벨 패턴
      • 컴포넌트 or 컴포넌트 간 특정 측면 구현하는 방법
    • 분석 패턴
      • 도메인 내의 개념적인 문제를 해결하는 데 초점
  • 패턴의 구성 요소는 클래스가 아니라 역할이다.
    • 역할은 좀 더 추상적인 개념이었다.
  • 패턴의 구성요소가 클래스와 메서드가 아니라 역할과 책임이다.
    • 구현 방법에 대한 제한이 없다는 뜻이다.
    • 패턴을 적용하기 위해 패턴이 제시하는 구조를 맹목적으로 따를 필요가 없다는 뜻
  • 어떤 디자인 패턴이 어떤 변경을 캡슐화하는지 이해하라.
  • 패턴을 남용하지 않기 위해서는 다양한 트레이드오프 관계 속에서 패턴을 적용하고 사용해 본 경험이 필요하다.
  • 정당한 이유 없이 사용된 패턴은 설계를 복잡하게 만드는 장애물이다.
    • 패턴은 비싸다. 반드시 그 가치가 있을 때만 사용이 정당화 된다.
• 프레임워크와 코드 재사용
  • 코드를 재사용함으로써 설계 아이디어를 재사용한다.
  • 설계 자체의 재사용을 중요시한다.
  • 변하는 부분과 변하지 않는 부분 별도의 패키지
    • 변하지 않는 부분 → 상위 패키지
  • 객체지향 설계에서 재사용성은 객체들 사이의 공통적인 협력 흐름으로부터 나온다.
    • 역할 사이의 공통적인 협력 흐름이 있다면, 다양한 문맥에 맞는 책임을 구현하면서 설계를 재사용할 수 있다.
  • 의존성 역전 원리(DIP)가 매우 중요하게 사용되는 필드다.
  <aside> 💡 프레임워크가 애플리케이션에 속하는 서브클래스 메서드를 호출한다.</aside>
  • 전체적 협력 흐름은 프레임워크가 담당, 특정한 기본 정책을 구현하는 것은 애플리케이션 개발자가 담당
  • 협력을 제어하는 것은 프레임워크 (상위 모듈)이다. 애플리케이션 개발자의 코드는 상위 모듈에 의해서 호출된다.
    • 제어가 프레임워크로 넘어가 버렸다.
• (의존성이 역전되었다!)