Chapter15 디자인 패턴과 프레임워크

디자인 패턴 - 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결방법

 - 설계를 재사용하기 위함

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

 

프레임 워크 - 설계와 코드를 함께 재사용하기 위한것.

 - 애플리케이션의 아키텍처를 구현 코드의 형태로 제공

 - 일관성 있는 협력을 제공하는 확장 가능한 코드.

 

---

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

 

소프트웨어 패턴

 

패턴이란 무엇인가?

• 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다
• 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다.
• 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다.
• 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다.

 내가 사용하는 패턴정의는 하나의 실무 컨텍스트(practical context)에서 유용하게 사용해왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어 idea 다. 아이디어라는 용어를 사용하는 이유는 어떤것도 패턴이 될 수 있기 때문이다. 패턴은 "GOF"에서 이야기하는 것처럼 협력하는 객체 그룹일 수도 있고, 코플리엔 Coplien 의 프로젝트 조직 원리일 수도 있다. 실무 컨텍스트라는 용어는 패턴이 실제 프로젝트의 실무 경험에서 비롯됐다는 사실을 반영한다. 흔히 패턴을 '발명했다'고 하지않고 '발견했다'고 말한다. 모델의 유용성이 널리 받아들여지는 경우에만 패턴으로 인정할 수 있기 때문에 이 말은 타당하다. 실무 프로젝트가 패턴보다 먼저지만 그렇다고 해서 실무 프로젝트의 모든 아이디어가 패턴인 것은 아니다 : 패턴은 개발자들이 다른 컨텍스트에서도 유용할 것이라고 생각하는 어떤 것이다.

마틴파울러의 <<Analysis Patterns>>

3의 규칙  Rule of Three

 

패턴은 경험의 산물

 

중요한 요소 - 패턴의 이름

 

모든 영역이 패턴의 대상

 

연관된 패턴들의 집합들이 모여 하나의 패턴 언어를 구성

 

 

패턴 분류

 

• 아키텍처 패턴  Architecture Pattern - 전체적인 구조 결정, 미리 정의된 서브시스템 제공, 언어나 프로그래밍 패러다임에 독립적.
• 분석패턴  Analysis Pattern - 도메인 내 개념적 문제 해결에 초점. 업무 모델링시 발견되는 공통적 구조 개념의 집합.
• 디자인 패턴 Design Pattern - 일반적인 설계문제 해결, 컴포넌트 사이 구고 서술, 언어나 패러다임에 독립적.
• 이디엄 Idiom - 디자인패턴 하위에 위치, 언어에 종속적, 언어의 기능을 사용해 컴포넌트 특정 부분 구현방법을 서술.

 

패턴과 책임-주도 설계

 

패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿.

 

패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다.

-> 시스템 안에 구현할 객체들의 역할, 책임, 협력 관계를 쉽게 구성 가능.

 

패턴의 구성요소는 클래스가 아니라 '역할'

 

Strategy 패턴 - 다양한 알고리즘을 동적으로 교체할 수 있는 역할과 책임 제공

Bridge 패턴 - 역할과 책임을 추상화와 구현의 두개의 커다란 집합으로 분해하여 설계를 확장가능하게 함.

Observer 패턴 - 객체간 결합도를 낮출 수 있는 역할과 책임의 집합 제공.

Composite 패턴 - 클라이언트가 개별 객체와 복합 객체를 동일하게 취급할 수 있음. 협력하는 객체의 수를 캡슐화

 

디자인 패턴의 구성요소가 클래스와 메서드가 아니라 역할과 책임이라는 사실이라는 것이 중요

-> 역할,책임,협력의 관점에서 유사성을 공유하는 것. 특정 구현방식의 강제 X

 

 

캡슐화와 디자인 패턴

 

추상클래스나 인터페이스를 이용해 변경을 캡슐화 하고 이를 구현하기 위해 객체 합성

 

상속을 이용 - 변경하지 않는 부분은 부모 클래스로, 변하는 부분은 자식 클래스로 분리하여 추상메소드를 이용해 변경을 캡슐화

-> Template Method 패턴 : 결합도가 높지만 알고리즘 교체 요구사항이 없을경우 복잡도를 낮춤

 

Decorator 패턴 - 객체합성을 사용, 객체의 행동을 동적으로 추가 할 수 있게 해주는 패턴

 

어떤 디자인 패턴이 어떤 변경을 캡슐화 하는지를 이해하는 것이 중요.

 

 

패턴은 출발점이다

 

패턴이 설계의 목표가 되어서는 안됨.

현재의 요구사항이나 기술, 프레임 워크에 적합하지 않다면 ( 컨텍스트 적절성 )

패턴을 그대로 따르지 말고 목적에 맞게, 문제에 적합하게 패턴을 수정하자

 

패턴은 복잡성의 가치가 단순성을 넘어설 때만 정당화

 

코드와 설계에 대한 지식, 패턴이 같이 공유되어야 함.

 

<패턴을 활용한 리펙터링> 을 참조하여 패턴을 목표로 리펙토링하고 그 이유를 이해해 볼것.

 

---

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

 

코드 재사용 대 설계 재사용

 

 디자인 패턴은 프로그래밍 언어에 독립적으로 재사용 가능한 설계 아이디어를 제공하는 것을 목적으로 함

-> 언어 특성에 맞춰 가공하고 구현코드 재작성해야함

 

다양한 도메인에 재사용 가능한 컴포넌트 개념은 적용하기 어려움

 

설계재사용과 코드 재사용을 적절히 조합 사용하자.

 

프레임워크란?

- 구조적 측면에서 : 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계

- 코드와 설계의 재사용 관점에서 : 애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징 할 수 있는 골격

 

- 어플리케이션 아키텍처 제공하고 공통 인터페이스들 뿐만아니라 재사용 가능한 컴포넌트들도 함께 제공

- 설계자체의 재사용 중시

 

 

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

 

협력을 구현하는 코드안의 의존성은 가급적이면 추상화를 향하도록 작성하자.

 

9장의 의존성 역전원칙에 기반하여 의존관계 설정

 

상위정책이 세부사항보다 더 다양한 상황에서 재사용될 수 있어야 함.

-> 상위정책과 세부 사항(변경) 모두 추상화에 의존하게 만듬.

 

변하는 것(세부사항)과 변하지 않는 것( 협력구조 )을 서로 분리

-> 별도의 패키지로 분리하여 배포단위로 관리

ex) 상위정책과 하위정책을 별도의 패키지로 분리 -> 상위정책 패키지를 떼어서 재사용 가능 

 

 

제어 역전 원리

 

상위정책을 재사용한다는것.

도메인에 존재하는 핵심 개념들 사이의 협력관계를 재사용 한다는 것을 의미

 

훌륭한 객체지향 설계는 의존성이 역전된 설계 : 프레임워크의 가장 기본적인 설계 매커니즘

제어흐름 주체 역시 역전시킴 - 제어역전 Inversion of Control, 할리우드 Hollywood 원리

 

프레임워크에 의해 제공된 것이 아닌 애플리케이션 컨텍스트에 따라 달라질 수 있는 특정한 동작 - 훅 Hook

 

프레임워크가 코드를 호출하고 의미 부여하기 전까지 코드는 수동적으로 존재함.

 

제어의 역전이 프레임워크의 핵심 개념이며, 코드 재사용을 가능하게 하는 것.