오브젝트 - Chapter 15 디자인 패턴과 프레임워크

• 디자인 패턴: 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 설계의 묶음이다.
• 프레임워크: 설계와 코드를 함께 재사용하기 위한 것
  • 프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공한다.
  • 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다.
  • 프레임워크는 각 애플리케이션 요구에 따라 적절하게 커스터마이징 할 수 있는 확장 포인트를 제공한다.
• 디자인 패턴과 프레임워크 모두 일관성 있는 협력과 관련이 있다.
  • 디자인 패턴은 특정한 변경을 일관성 있게 다룰 수 있는 협력 템플릿을 제공한다.
  • 프레임워크는 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공한다.

01 디자인 패턴과 설계 재사용

소프트웨어 패턴

• 패턴이란 무엇인가?를 논의할 때면 반복적으로 언급되는 몇 가지 핵심적인 특징
  • 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다.
  • 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다.
  • 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다.
  • 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다.
• 패턴은 한 컨텍스트에서 유용한 동시에 다른 컨텍스트에서도 유용한 '아이디어'이다.
• 패턴이 지닌 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점이다
• 패턴의 '이름'은 커뮤니티가 공유할 수 있는 중요한 어휘집을 제공한다. 패턴에 이름은 높은 수준의 대화를 가능하게 하는 원천이다
• 크리스토퍼 알렉산더는 "연관된 패턴들의 집합들이 모여 하나의 패턴 언어(Pattern Language)를 구성한다. "고 정의하고 있다.
• 패턴 언어는 연관된 패턴 카테고리뿐만 아니라 패턴의 생성 규칙과 함께 패턴 언어에 속한 다른 패턴 과의 관계 및 협력 규칙을 포함한다

패턴 분류

• 패턴의 분류
  • 아키텍처 패턴(Architecture Pattern)
  • 분석 패턴(Analysis Pattern)
  • 디자인 패턴(Design Pattern)
  • 이디엄(Idiom)
• 디자인 패턴은 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다
• 디자인 패턴은 중간 규모의 패턴으로 특정한 설계 문제를 해결하는 것을 목적으로 하며 프로그래밍 언어나 프로그래밍 패러다임의 독립적이다
• 디자인 패턴의 상웨에는 소프트웨어의 전체적인 구조를 결정하기 위해 사용할 수 있는 아키텍처 패턴이 있다. (프로그래밍 언어나 프로그래밍 패러다임의 독립적이다)
• 디자인 패턴의 하위에는 이디엄이 위치한다. 이디엄은 특정 프로그램밍 언어에만 국한된 하위 레벨 패턴이다
• 분석패턴은 도메인 내에서 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합이다

패턴과 책임-주도 설계

• 객체지향 설계에서 가장 중요한 일은 올바른 책임을 올바른 객체에게 할당하고 객체 간의 유연한 협력 관계를 구축하는 일이다.
• 책임과 협력의 윤곽은 캡슐화, 크기, 의존성, 유연성, 성능, 확장 가능성, 재사용성 등의 다양한 요소들의 트레이드오프를 통해 결정된다
• 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.
• 특정한 상황에 적용 가능한 패턴을 잘 알고 있다면 책임 주도 설계의 절차를 하나하나 따르지 않고도 시스템 안에 구현할 개체들의 역할과 책임, 협력, 관계를 빠르고 손쉽게 구성할 수 있다
• 패턴의 구성 요소는 클래스가 아니라 '역할'이다.
• 어떤 구현 코드가 어떤 디자인 패턴을 따른다고 이야기할 때는 역할 책임 협력에 관점에서 유사성을 공유한다는 것이지 특정한 구현 방식을 강제한다는 것이 아니라는 점을 이해하는 것 역시 중요하다

캡슐화와 디자인 패턴

• 대부분의 디자인 패턴의 목적은 특정한 변경을 캡슐화함으로써 유연하고 일관성 있는 협력을 설계할 수 있는 경험을 공유하는 것이다.
• 디자인 패턴에서 중요한 것은 디자인 패턴의 구현 방법이나 구조가 아니다.
• 어떤 디자인 패턴이 어떤 변경을 캡슐화 하는지를 이해하는 것이 중요하다.

패턴은 출발점이다

• 패턴은 출발점이지 목적지가 아니다.
• 패턴이 설계의 목표가 돼서는 안 된다.
• 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 패턴을 그대로 따르지 말고 목적에 맞게 패턴을 수정하라.
• 패턴을 사용하면서 부딪히게 되는 대부분의 문제는 패턴을 맹목적으로 사용할 때 발생한다.
• 해결하려는 문제가 아니라 패턴이 제시하는 구조를 맹목적으로 따르는 것은 불필요하게 복잡하고 난해하며 유지 보수 하기 어려운 시스템을 낳는다.
• 패턴은 복잡성의 가치가 단순성을 넘어설 때만 정당화돼야 한다
• 패턴을 적용할 때는 항상 설계를 좀 더 단순하고 명확하게 만들 수 있는 방법이 없는지 고민해야 한다.
  또한 코드를 공유하는 모든 사람들이 적용된 패턴을 알고 있어야 한다.

02 프레임워크와 코드 재사용

코드 재사용 대 설계 재사용

• 디자인 패턴은 프로그래밍 언어에 독립적으로 재사용 가능한 설계 아이디어를 제공하는 것을 목적으로 한다.
  따라서 언어에 종속적인 구현 코드를 정의하지 않기 때문에 디자인 패턴을 적용하기 위해서는 설계 아이디어를 프로그래밍 언어의 특성에 맞춰 가공해야 하고 매번 구현 코드를 재작성해야 한다는 단점이 있다.
• 재사용 관점에서 설계 재사용보다 더 좋은 방법은 코드 재사용이다.
• 가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것이다.
• "설계를 재사용하면서도 유사한 코드를 반복적으로 구현하는 문제를 피할 수 있는 방법은 없을까?" 이 질문에 대한 객체지향 커뮤니티의 대답이 바로 프레임워크이다.
• 프레임워크란
  '추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계'
  또는 '애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션의 골격(skeleton)'을 의미한다.
  • 첫 번째 정의가 프레임워크의 구조적인 측면에 초점을 맞추고 있다면
  • 두 번째 정의는 코드와 설계의 재사용이라는 프레임워크의 사용 목적에 초점을 맞춘다.
• 프레임워크는 코드를 재사용함으로써 설계 아이디어를 재사용한다.

상위 정책과 하위 정책으로 패키지 분리 하기

• 프레임워크의 핵심은 추상 클래스나 인터페이스와 같은 추상화라고 할 수 있다
• 추상클래스와 인터페이스가 일관성 있는 협력을 만드는 핵심 재료라는 것을 기억하라
• 협력을 일관성 있고 유연하게 만들기 위해서는 추상화를 이용해 변경을 캡슐화해야 한다
  그리고 협력을 구현하는 코드 안에 의존성은 가급적이면 추상 클래스나 인터페이스와 같은 추상화를 향하도록 작성해야 한다
• 객체지향 이전에 구조적인 설계와 같은 전통적인 소프트웨어 개발방법의 경우 상위 레벨 모듈이 하위 레벨 모듈에, 그리고 상위 정책이 구체적인 세부사항에 의존하도록 소프트웨어를 구성한다
  하지만 상위 정책은 상대적으로 변경에 안정적이지만 세부 사항은 자주 변경 된다.
• 만약 변하지 않는 상위 정책이 자주 변하는 세부사항의 의존 한다면 변경에 대한 파급효과로 인해 상위 정책이 불안정해질 것이다.
• 그리고 상위 정책이 세부사항에 비해 재사용될 가능성이 높다
• 요점은 상위 정책이 세부사항 보다 더 다양한 상황에서 재사용될 수 있어야 한다는 것이다.
• 이 문제를 해결할 수 있는 가장 좋은 방법은 의존성 역전 원칙에 맞게 상위 정책과 세부사항 모두 추상화 의존하게 만드는 것이다
• 의존성 역전 원칙의 관점에서 세부 사항은 '변경'을 의미한다
• 이를 위한 첫걸음은 변하는 부분과 변하지 않는 부분을 별도의 패키지로 분리하는 것이다
• 의존성 역전 원칙에 따라 추상화에만 의존하도록 의존성의 방향을 조정하고 추상화를 경계로 패키지를 분리했기 때문에 세부사항을 구현한 패키지는 항상 상위의 정책을  구현한 패키지 의존 해야 한다.

제어 역전 원리(Inversion Of Control, IoC)

• 상위 정책을 재사용한다는 것은 결국 도메인의 존재하는 핵심개념들 사이에 협력 관계를 재사용한다는 것을 의미한다
• 객체지향 설계의 재사용성은 개별 클래스가 아니라 객체들 사이에 공통적인 협력 흐름으로부터 나온다
• 의존성 역전 원리는 전통적인 설계방법과 객체지향을 구분하는 가장 핵심적인 원리이다.
• 의존성 역전 원칙에 따라 구축되지 않은 시스템은 협력 흐름을 재사용할 수 없으며 변경에 유연하게 대처할 수도 없다.
• 로버트 마틴은 "훌륭한 객체지향 설계는 의존성이 역전된 설계"라는 점을 강조한다
• 의존성 역전 원리는 프레임워크의 가장 기본적인 설계 메커니즘이다
• 의존성 역전은 의존성의 방향뿐만 아니라 제어 흐름에 주체 역시 역전시킨다. 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어흐름의 주체가 이동한다. 이를 제어 역전 원리라고 한다
• 프레임워크에서는 일반적인 해결책만 제공하고 애플리케이션에 따라 달라질 수 있는 특정한 동작은 비워 둔다 그리고 이렇게 완성되지 않은 채로 남겨진 동작을 훅(hook)이라고 부른다