Skip to main content

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

  • 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부릅니다.
  • 프레임 워크는 설계와 코드를 함께 재사용하기 위한 것입니다.
    • 프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공합니다.
    • 프레임워크는 각 애플리케이션 요구에 따라 적절하게 커스터마이징할 수 있는 확장 포인트를 제공합니다.
  • 디자인 패턴과 프레임워크 모두 협력을 일관성 있게 만들기 위한 방법입니다.

01. 디자인 패턴과 설계 재적용#

소프트웨어 패턴#

  • 패턴이 무엇인가를 논의할 때 반복적으로 언급되는 몇 가지 특징이 있습니다.
    • 반복적으로 발생하는 문제와 해법의 쌍으로 정의
    • 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있고, 이 지식을 다른 사람과 의사소통할 수 있습니다.
    • 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕습니다.
    • 패턴의 요점은 패턴이 실무에서 탄생했다는 점입니다.
  • 패턴은 한 컨텍스트에서 유용한 동시에 다른 컨텍스트에서도 유용한 '아이디어'입니다.
  • 패턴이 지닌 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점입니다.
  • 연관된 패턴들의 집합들이 모여 하나의 패턴 언어(Pattern Langueage)를 구성합니다. 다만 패턴 언어에서의 제약 조건을 완화하기 위해 패턴 시스템(Pattern System)도 제안되었으나 현재는 같은 의미로 쓰이고 있습니다.

패턴 분류#

  • 패턴을 분류하는 가장 일반적인 방법은 패턴의 범위나 적용 단계에 따라 아키텍처 패턴(Architecture Pattern), 분석 패턴(Analysis Pattern), 디자인 패턴(Design Pattern), 이디엄(Idiom) 의 4가지로 분류하는 것입니다.
  • 디자인 패턴의 상위에 소프트웨어의 전체적인 구조를 결정하기 위해 사용할 수 있는 아키텍처 패턴이 위치합니다.
    • 아키텍처 패턴은 미리 정의된 서브시스템을 제공하고, 각 서브시스템들의 책임을 정의하며, 서브 시스템들 사이의 관계를 조직화하는 규칙과 가이드라인을 포함합니다.
  • 디자인 패턴의 하위에는 이디엄이 위치합니다.
    • 이디엄은 특정 프로그래밍에 국한된 하위 레벨 패턴으로, 주어진 언어의 기능을 사용해 컴포넌트, 혹은 컴포넌트 간의 특정 측면을 구현하는 방법을 서술합니다.
  • 아키텍처 패턴, 디자인 패턴, 이디엄이 주로 기술적인 문제를 해결하는 데 초점을 맞춘다면 분석 패턴은 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춥니다.

패턴과 책임-주도 설계#

  • 객체지향 설계에서 가장 중요한 일은 올바른 책임을 올바른 객체에게 할당하고 객체 간의 유연한 협력 관계를 구축하는 일입니다.
  • 책임과 협력의 윤곽은 캡슐화, 크기, 의존성, 유연성, 성능, 확장 가능성, 재사용성 등의 다양한 요소들이 트레이드오프를 통해 결정됩니다.
  • 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿입니다.
  • 패턴의 구성 요소는 클래스가 아닌 '역할'입니다.
    • 이는 패턴 템플릿을 구현할 수 있는 다양한 방법이 존재한다는 사실을 암시합니다.

캡슐화와 디자인 패턴#

  • 몇 가지 이례적인 경우를 제외하면 널리 알려진 대부분의 디자인 패턴은 협력을 일관성 있고 유연하게 만드는 것을 목표로 합니다.
  • 캡슐화하는 방법이 합성만 있는 것은 아니고, 상속도 있으나 이 경우 추상 메서드를 이용해 변경을 캡슐화해야 하고 이를 TEMPLATE METHOD라고 합니다.
  • Template Method 패턴은 부모 클래스가 알고리즘의 기본 구조를 정의하고 구체적인 단계는 자식 클래스에서 정의하게 함으로써 변경을 캡슐화할 수 있는 디자인 패턴입니다.

패턴은 출발점이다#

  • 패턴은 출발점이지 목적지가 아닙니다.
  • 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 패턴을 그대로 따르는 것이 아닌 목적에 맞게 수정이 필요합니다.
  • 해결하려는 문제가 아니라 패턴이 제시하는 구조를 맹목적으로 따르는 것은 불필요하게 복잡하고, 난해하며, 유지보수하기 어려운 시스템을 낮습니다.
  • 정당한 이유 없이 사용된 모든 패턴은 설계를 복잡하게 만드는 장애물입니다.

02. 프레윔워크와 코드 재사용#

코드 재사용 대 설계 재사용#

  • 디자인 패턴은 프로그래밍 언어에 독립적으로 재사용 가능한 설계 아이디어를 제공하는 것을 목적으로 합니다.
  • 재사용 관점에서 설계 재사용보다 더 좋은 방법은 코드 재사용입니다.
  • 가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것입니다.
  • 프레임워크란 '추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계'입니다.
  • 프레임워크는 코드를 재사용함으로써 설계 아이디어를 재사용합니다.

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

  • 프레임워크의 핵심은 추상 클래스나 인터페이스와 같은 추상화라고 할 수 있습니다.
  • 추상 클래스와 인터페이스가 일관성 있는 협력을 만드는 핵심 재료입니다.
  • 일반적으로 상위 정책이 더 많이 쓰이기에 세부 사항보다 더 다양한 상황에서 재사용될 수 있어야 합니다.
  • 의존성 역전 원칙의 관점에서 세부 사항은 '변경'을 의미합니다. 따라서 변하는 것과 변하지 않는 것을 서로 분리해야합니다.

제어 역전 원리#

  • 상위 정책을 재사용한다는 것은 결국 도메인에 존재하는 핵심 개념들 사이의 협력 관계를 재사용하는 것을 의미합니다.
  • 의존성을 역전 시킨 객체지향 구조에서는 반대로 프레임워크가 애플리케이션에 속하는 서브 클래스의 메서드를 호출합니다.
  • 협력을 제어하는 것은 프레임워크라는 것에 주목해야합니다.

나아가기#

  • 새로운 기술의 학습 단계는 '따라하는 수준', '분리 수준', '거침없는 수준'으로 구분됩니다.
  • 분리 수준으로 나가기 위해서는 아래와 같은 방법을 아는 것이 중요합니다.
    • 디자인 패턴(Design Pattern)
    • 리팩터링(Refactoring)
    • 테스트-주도 개발(Test-Driven Development)
  • 다만, 어떤 기법도 홀로 존재할 수 없습니다.
Last updated on