15. 디자인 패턴과 프레임워크
디자인 패턴
- 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법
- 협력을 재사용할 수 있게 만들기 위해 재사용할 수 있는 설계의 묶음
프레임워크
- 설계와 코드를 함께 재사용하기 위한 것
- 일관성있는 협력을 제공하는 확장 가능한 코드
01. 디자인 패턴과 설계 재사용
디자인 패턴의 구성요소는 클래스와 메서드가 아니라 역할과 책임이다.
소프트웨어 패턴
- 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다.
- 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 사용해 다른 사람과 의사소통 할 수 있다.
- 패턴은 추상적인 원칙과 실제 코드 사이의 간극을 매워주며 실질적인 코드 작성을 돕는다.
- 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다.
패턴 분류
- 아키택처 패턴
- 구체적인 소프트웨어 아키텍처를 위한 템플릿을 제공하며, 디자인 패턴과 마찬가지로 프로그래밍 언어나 프로그래밍 패러다임에 독립적이다.
- 디자인 패턴
- 중간 규모의 패턴으로, 특정 설계 문제를 해결하는 것을 목적으로 하며, 프로그래밍 언어나 프로그래밍 패러다임에 독립적이다.
- 이디엄
- 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴.
- 분석 패턴
- 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춘다. 분석 패턴은 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합이다.
패턴과 책임 주도 설계:
패턴을 따르면 특정한 상황에 적용할수 있는 설계를 쉽고 빠르게 떠올릴 수 있다. 특정한 상황에 적용 간으한 패턴을 잘 알고 있다면 책임 주도 설계이 절차를 하나 하나 다르지 않고도 싯템 안에 구현할 객체들의 역할과 책임, 협력 관계를 빠르고 손쉽게 구성할 수 있다.
캡슐화와 디자인 패턴
몇가지 이례적인 경우를 제외하면 널리 알려진 대부분의 디자인 패턴은 협력을 일관성있고 유연하게 만드는 것을 목적으로 한다. 따라서 각 디자인 패턴은 특정한 변경을 캡슐화하기 위한 독자적인 방법을 정의하고 있다.
Composite Pattern: 중복할인 정책 구조(8장)
개별 객체와 복합 객체라는 객체의 수와 관련된 변경을 캡슐화.
Strategy Pattern: 영화 예매 시스템
알고리즘의 변경을 캡슐화하는 것이 목적. 이를 구현하기 위해 객체의 합성을 이용한다.
Template Method Pattern: 영화 예매 시스템(8장)
부모 클래스가 알고리즘 기본 구조를 정의하고 구체적인 단계는 자식 클래스에게 정의하게 함으로써 변경을 캡슐화할 수 있는 디자인 패턴.
Decorator Pattern: 핸드폰 과금 시스템
객체의 행동을 동적으로 추가할 수 있게 해주는 패턴으로서 기본적으로 객체의 행동을 결합하기 위해 객체 합성을 사용한다. 선택적인 행동의 개수와 순서에 대한 변경을 캡슐화할 수 있다.
패턴은 출발점이다
패턴이 설계의 목표가 되어서는 안 된다. 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않는다면 패턴을 그대로 따르지 말고 현재의 문제에 적합하도록 수정할 수 있아야 한다.
02. 프레임워크와 코드 재사용
프레임워크란 구조적인 측면에서 '추상 클래스나 인터페이스를 정의하고 인스턴스의 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계'로 볼 수도 있고 사용 목적 측면에서 '애플리케이션 개발자가 현재 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션' 으로 볼 수 있다.
프레임워크는 코드를 재사용 함으로서 설계 아이디어를 재사용한다. 프레임워크는 애플리케이션의 아키텍처를 제공하며 문제 해결에 필요한 설계 과정과 이에 필요한 기반 코드를 함께 포함한다. 또한 애플맄케이션을 확장할 수 있도록 부분으로 구현된 추상 클래스와 인터페이스 집합 뿐만 아니라 추가적인 작업 없이도 재사용 가능한 다양한 종류의 컴포넌트도 함께 제공한다.
상위 정책과 하위 정책으로 패키지 분리하기
프레임워크의 핵심은 추상 클래스나 인터페이스와 같은 추상화 이다. 추상클래스와 인터페이스는 일관성 있는 협력을 만드는 핵심 재료 이다. 협력을 일관성 있고 유연하게 만들려면 추상화를 이용해 변경을 캡슐화 해야 한다. 그리고 협력하는 코드의 의존성은 가급적 추상클래스나 인터페이스와 같은 추상화를 향하도록 작성해야 한다.
변경에 안정적이며 재사용될 가능성이 높은 추상화에 의존하는 것은 전통적인 설계, 개발방법과는 다른 방법 이다. 변하는 것과 변하지 않는 부분을 별도의 패키지로 분리한다. 그리고 변하는 부분(세부 사항을 구현한 부분)은 항상 상위 정책을 구현한 패키지에 의존하게 한다. 좀더 나아가 상위정책을 구현한 패키지가 충분히 안정적이고 성숙했다면 하위정책 패키지로부터 완전히 분리해 별도의 패키지로 만들 수 있다.
이렇게 상위정책 패키지와 하위정책 패키지를 완전히 분리하면 상위정책 패키지를 여러 어플리케이션에서 재사용할 수 있는 기반(프레임워크)가 마련 된 것이다.
제어 역전 원리
상위 정책을 재사용할 수 있었던 것은 의존성 역전 이라는 원리라는 강력한 지원군이 있었기 때문이다. 의존성 역전은 의존성의 방향 뿐 아니라 제어의 방향도 역전시킨다.
전통적인 경우(상위 정책이 세부 정책에 의존하는 경우) 애플리케이션의 코드가 라이브러리나 툴킷의 코드를 호출하지만 의존성을 역전시킨 객체지향 구조에서는 상위정책(프레임워크)가 애플리케이션에 해당하는 서브클래스의 메서드를 호출한다. 이를 제어 역전 원리 혹은 할리우드 원리라고 한다
과거엔 우리가 직접 라이브러리의 코드를 호출했지만 지금은 그저 프레임워크가 호출하는 코드를 작성해야 한다. 제어가 우리에게서 프레임워크로 돌아간 것이다.