[오브젝트] 15장. 디자인 패턴과 프레임워크

스터디 메인 페이지

목차

- ☆ 표시가 붙은 부분은 스터디 중 나온 얘기 혹은 제 개인적인 생각이나 제가 이해한 방식을 적어놓은 것으로, 책에 나오지 않는 내용입니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

- 모든 이미지의 출처는 오브젝트(조용호 저) 책 입니다.

 

---

 

CHAPTER 15. 디자인 패턴과 프레임워크

⚈ 디자인 패턴 - 협력을 일관성 있게 만들기 위해 재사용할 수 있는 설계의 묶음

• 애플리케이션을 설계하다 보면 어떤 요구사항을 해결하기 위해 과거에 경험했던 유사한 해결 방법을 다시 사용하는 경우가 있다.
• 이처럼 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부른다.
• 디자인 패턴의 목적은 설계를 재사용하는 것이다.
• 디자인 패턴은 다양한 변경을 다루기 위해 반복적으로 재사용할 수 있는 설계의 묶음이다.
• 디자인 패턴은 특정한 변경을 일관성 있게 다룰 수 있는 협력 탬플릿을 제공한다.

 

⚈ 프레임워크 - 일관성 있는 협력을 제공하는 확장 가능한 코드

• 디자인 패턴이 설계를 재사용하기 위한 것이라면 프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다.
• 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 다양한 환경에서 테스트를 거친 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다.
• 프레임워크는 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 탬플릿을 제공한다.

 

---

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

⚈ 패턴 : 하나의 실무 컨텍스트(practical context)에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어(idea)

 

⚈ 패턴으로 인정하기 위한 조건 - '3의 규칙(Rule of Three)'

• 최소 세 가지의 서로 다른 시스템에 특별한 문제 없이 적용할 수 있고 유용한 경우에만 패턴으로 간주할 수 있다.

 

⚈ 패턴의 가치

• 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다 (패턴은 경험의 산물)
• 패턴의 이름은 커뮤니티가 공유할 수 있는 중요한 어휘집을 제공한다. ("인터페이스를 하나 추가하고 이 인터페이스를 구체화하는 클래스를 만든 후 객체의 생성자나 setter 메서드에 할당해서 런타임 시에 알고리즘을 바꿀 수 있게 하자" 대신 "STRATEGY 패턴을 적용하자")

 

⚈ 패턴 분류

• 디자인 패턴(Design Pattern) : 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다.
• 아키텍쳐 패턴(Architecture Pattern) : 디자인 패턴의 상위. 소프트웨어의 전체적인 구조를 결정하기 위해 사용
• 이디엄(Idiom) : 디자인 패턴의 하위. 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴.
• 분석 패턴(Analysis Pattern) : 위 3개가 주로 기술적인 문제를 해결하는 데 초점을 맞추고 있다면 분석 패턴은 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춘다. 분석 패턴은 도메인 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합이다.

 

⚈ 대부분의 디자인 패턴은 협력을 일관성 있고 유연하게 만드는 것을 목적으로 한다.

• 영화 예매 시스템의 경우 객체 합성을 이용한 STRATEGY 패턴을 적용한 예이다. STRATEGY 패턴의 목적은 알고리즘의 변경을 캡슐화하는 것이다.

• 변경 캡슐화를 위해 상속을 이용할 수도 있다. 이하는 변경을 캡슐화하기 위해 상속을 사용한 예다. 알고리즘을 캡슐화하기 위해 합성 관계가 아닌 상속 관계를 사용하는 것을 TEMPLATE METHOD 패턴이라고 부른다. 변경하지 않는 부분은 부모 클래스로, 변하는 부분은 자식 클래스로 분리함으로써 변경을 캡슐화한다.

• 핸드폰 과금 시스템 설계는 DECORATOR 패턴을 기반으로 한다. DECORATOR 패턴은 객체의 행동을 동적으로 추가할 수 있게 해주는 패턴으로 기본적으로 객체의 행동을 결합하기 위해 객체 합성을 사용한다. DECORATOR 패턴은 선택적인 행동의 개수와 순서에 대해 변경을 캡슐화할 수 있다.

 

⚈ 패턴은 출발점이다.

• 패턴은 출발점이지 목적지가 아니다.
• 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 패턴을 그대로 따르지 말고 목적에 맞게 패턴을 수정하라.
• 패턴을 사용하면서 부딪히게 되는 대부분의 문제는 패턴을 맹목적으로 사용할 때 발생한다.
• 패턴에 처음 입문한 사람들은 패턴의 강력함에 매료된 나머지 아무리 사소한 설계라도 패턴을 적용해보려고 시도한다. 그러나 명확한 트레이드오프 없이 패턴을 남용하면 설계가 불필요하게 복잡해지게 된다.
• 정당한 이유 없이 사용된 모든 패턴은 설계를 복잡하게 만드는 장애물이다.

 

---

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

⚈ 가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것이다.

• 추상적인 수준에서의 설계 재사용을 강조하는 디자인 패턴은 재사용을 위해 매번 유사한 코드를 작성해야만 한다.
• 설계를 재사용하면서도 유사한 코드를 반복적으로 구현하는 문제를 피할 수 있는 방법은 없을까? -> 프레임워크!

 

⚈ 프레임워크

• 프레임워크의 구조적인 측면 : '추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계'
• 코드와 설계의 재사용이라는 프레임워크의 목적 측면 : '애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징할 수 있는 애플리케이션의 골격(skeleton)'

 

⚈ 제어 역전 원리

• 의존성 역전 원리는 전통적인 설계 방법과 객체지향을 구분하는 가장 핵심적인 원리다.
• "좋은 객체지향 설계의 증명이 바로 의존성의 역전이다. ... 그 의존성이 역전돼 있지 않다면. 절차적 설계를 갖는 것이다."
• 의존성을 역전시킨 객체지향 구조에서는 반대로 프레임워크가 애플리케이션에 속하는 서브클래스의 메서드를 호출한다. 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다. 즉, 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전(Inversion of Control) 원리, 또는 할리우드(Hollywood) 원리라고 한다.

 

⚈ 프레임워크에서는 일반적인 해결책만 제공하고 애플리케이션에 따라 달라질 수 있는 특정한 동작은 비워둔다. -> 이렇게 완성되지 않은 채로 남겨진 동작을 훅(hook)이라고 부른다.

• 재정의된 훅은 제어 역전 원리에 따라 프레임워크가 원하는 시점에 호출된다.

 

⚈ 제어 역전

• 우리는 프레임워크가 적절한 시점에 실행할 것으로 예상되는 코드를 작성할 뿐이다.
• 과거에는 우리가 직접 라이브러리의 코드를 호출했지만 객체지향의 시대에는 그저 프레임워크가 호출하는 코드를 작성해야만 한다.
• 제어가 우리에게서 프레임워크로 넘어가 버린 것이다.