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

15장은 설계를 재사용하는 디자인 패턴과 코드를 재사용하는 프레임워크에 대해 설명하고, 이전 movie 예제에 적용된 디자인 패턴을 소개한다. 

 

디자인 패턴이란? 

- 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법이다(설계 재사용).

- 디자인 패턴은 특정 정황(context)내에서 일반적인 설계 문제(problem)를 해결(solution)하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다(p.516).

- 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다(p.517).

- 특정한 변경을 캡슐화함으로써 협력을 일관성 있고 유연하게 해준다. 따라서, 어떤 디자인 패턴이 어떤 변경을 캡슐화하는지를 이해하는 것이 중요하다. 

 

 

Strategy 패턴

• 다양한 알고리즘을 동적으로 교체할 수 있는 역할과 책임의 집합 제공

Bridge 패턴

• 추상화의 조합으로 인한 클래스의 폭발적인 증가 문제를 해결하기 위해 역할과 책임을 추상화와 구현의 두 개의 커다란 집합으로 분해함으로써 설계를 확장 가능하게 만듦

Observer 패턴

• 유연한 통지 메커니즘을 구축하기 위해 객체 간의 결합도를 낮출 수 있는 역할과 책임의 집합 제공

Composite 패턴

• client가 개별 객체와 복합 객체를 동일하게 취급할 수 있음. component, composite, leaf으로 구성됨
• 개별 객체와 복합 객체라는 객체의 수와 관련된 변경을 캡슐화하는 것이 목적임

Template Method 패턴

• 알고리즘을 캡슐화하기 위해 합성 관계가 아닌 상속 관계를 사용하는 것
• 추상 클래스나 인터페이스를 사용해 변경을 캡슐화하는 합성과 달리 상속을 사용할 경우에는 추상 메서드를 이용해 변경을 캡슐화해야 함
• 부모 클래스가 알고리즘의 기본 구조를 정의하고 구체적인 단계는 자식 클래스에서 정의하게 함으로써 변경을 캡슐화할 수 있는 디자인 패턴

Decorator 패턴

• 객체의 행동을 동적으로 추가할 수 있게 해주는 패턴으로서 기본적으로 객체의 행동을 결합하기 위해 객체 합성 사용
• 선택적인 행동의 개수와 순서에 대한 변경을 캡슐화 할 수 있음

헤드퍼스트 디자인 패턴 책에도 비슷한 내용이 나오는데, 패턴을 너무 함부로 타당한 이유 없이 적용하면 안된다고 한다. 어떤 패턴을 적용하면 안되는 지도 알아야 하고 이유없이 적용된 패턴은 코드를 읽는 사람을(특히, 패턴에 익숙한 사람들) 혼란스럽게 할 뿐이다. 

 

패턴은 복잡성의 가치가 단순성을 넘어설 때만 정당화돼야 한다. p.522

패턴을 향해 리팩터링하기 위해 참조할 수 있는 리팩터링 카탈로그 제공

 

 

프레임워크란?

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

- 애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션의 골격 (코드 재사용)

의존성을 역전시킨 객체지향 구조에서는 반대로 프레임워크가 애플리케이션에 속하는 서브클래스의 메서드를 호출한다. 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다. 즉, 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전(Inversion of Control) 원리, 또는 할리우드(Hollywood) 원리라고 한다. p.529