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

0. 서론 

---

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

 

디자인 패턴은 다양한 변경을 다루기 위해 반복적으로 재사용할 수 있는 설계의 묶음이다. 디자인 패턴이 설계를 재사용하기 위한 것이라면 프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다. 

 

프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공한다. 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 다양한 환경에서 테스트를 거친 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다. 

 

디자인 패턴과 프레임워크 모두 협력을 일관성 있게 만들기 위한 방법이다. 

 

 

1. 디자인 패턴과 설계 재사용 

---

소프트웨어 패턴 

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

 

패턴 분류 

• 아키텍처 패턴 
  • 디자인 패턴의 상위에는 소프트웨어의 전체적인 구조를 결정하기 위해 사용할 수 있는 아키텍처 패턴이 존재하며 미리 정의된 서브시스템들을 제공하고, 각 서브시스템들의 책임을 정의하며, 서브시스템 사이의 관계를 조직화하는 규칙과 가이드라인을 포함한다.
• 디자인 패턴
  • 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다.
• 분석 패턴
  • 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춘다. 
  • 분석 패턴은 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합이다.
• 이디엄
  • 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴으로, 주어진 언어의 기능을 사용해 컴포넌트 혹은 컴포넌트 간의 특정 측면을 구현하는 방법을 서술한다.

 

패턴과 책임-주도 설계

• 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿
• 패턴의 세부적인 내용이 중요하다기보다 특정 상황에서 적용할 수 있는 설계를 빠르고 쉽게 떠올릴 수 있다는 사실 중요한 것이다.
• 패턴의 구성 요소는 클래스와 메서드가 아닌 역할과 책임이다.

 

캡슐화와 디자인 패턴 

각 패턴별 소개 

 

STRATEGY 패턴

알고리즘의 변경을 캡슐화 하는것이 목적이고, 이를 구현하기 위해 객체 합성을 이용한다.

 

TEMPLATE METHOD 패턴 

알고리즘을 캡슐화 하기 위해 합성이 아닌, 상속 관계를 이용한다. 

 

DECORATOR 패턴 

개인적으로, 관심이 많던 패턴이기도 하고... 따로 찾아봤던 기억이 있는 패턴이다. 

 

객체의 행동을 동적으로 추가할 수 있게 해주는 패턴으로서 기본적으로 객체의 행동을 결합하기 위해 객체의 합성을 사용한다. 

선택적인 행동의 개수와 순서에 대한 변경을 캡슐화 할 수 있다. 

 

2. 프레임워크와 코드 재사용 

코드 재사용 대 설계 재사용

디자인 패턴을 적용하기 위해선 설계 아이디어를 프로그래밍 언어의 특성에 맞춰 가공해야 하고 매번 구현 코드를 재 작성해야 한다는 단점이 있다. 

 

재사용 관점에서 설계 재사용보다 더 좋은 방법은 코드 재사용이다. 그러나 애플리케이션과 도메인의 다양성으로 인해 코드 재사용만을 강조하는 컴포넌트는 현실적이지 않다는 사실이 드러났다.

 

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

 

추상적인 수준에서의 설계 재사용을 강조하는 디자인 패턴은 재사용을 위해 매번 유사한 코드를 작성해야 한다.

 

이런 문제를 피하기 위한 방법이 바로 프레임워크이다.

 

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

 

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

• 객체지향 이전의 전통적인 소프트웨어 개발 방법의 경우 상위 레벨 모듈이 하위 레벨 모듈에, 상위 정책이 세부적인 사항에 의존하도록 구성한다. 
• 상대적으로 상위 정책은 변경에 안정적이지만 세부 사항은 자주 변경된다. 그러므로 상위 정책은 세부 사항에 비해 재사용될 가능성이 높다. 
• 변하지 않는 상위 정책이 자주 변하는 세부 사항에 의존한다면 변경에 대한 파급효과로 인해 상위 정책이 불안정해진다. 
• 변하는 부분과 변하지 않는 부분을 별도의 패키지로 분리를 하면 세부 구체 클래스들은 별도의 패키지로 분리된다.
• 의존성 역전 원칙(DIP)에 따라 추상화에만 의존하도록 의존성의 방향을 조정하고 추상화를 경계로 패키지를 분리하기에 세부 사항을 구현한 패키지는 항상 상위 정책을 구현한 패키지에 의존해야 한다.
• 상위 정책 패키지와 하위 정책 패키지를 물리적으로 완전히 분리하고 나면 상위 정책 패키지를 여러 애플리케이션에서 재사용할 수 있는 기반이 마련된다. 이로서 재사용 가능한 로직을 구현한 프레임워크가 완성된 것이다.

 

제어 역전 원리

• 의존성의 역전은 의존성의 방향뿐만 아니라 제어 흐름의 주체 역시 역전시킨다.
• 의존성을 역전시킨 객체지향 구조에서는 프레임워크가 애플리케이션에 속하는 서브클래스의 메서드를 호출한다. 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다.
• 즉, 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전 원리, 또는 할리우드 원리라고 한다.