소프트웨어 패턴

• 패턴이란 무엇인가
  • 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다.
  • 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다.
  • 패턴의 요점은 패턴이 실무에서 탄생했다는 것이다.
• 하나의 실무 컨텍스트에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어

  • 패턴은 경험의 산물

  • 패턴은 지식 전달과 커뮤니케이션의 수단으로 활용 가능

    → 가장 중요한 것은 패턴의 이름!

패턴 분류

• 가장 일반적인 분류
  • 아키텍처 패턴 (Architecture Pattern)
  • 분석 패턴 (Analysis Pattern)
  • 디자인 패턴 (Design Pattern)
  • 이디엄 (Idiom)
• 디자인 패턴
  • 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술
  • 특정한 설계 문제를 해결하는 것이 목적
  • 프로그래밍 언어나 프로그래밍 패러다임에 독립적
• 아키텍처 패턴 (디자인 패턴의 상위)
  • 미리 정의된 서브시스템들을 제공하고, 각 서브시스템들의 책임을 정의하며, 서브시스템들 사이의 관계를 조직화하는 규칙과 가이드라인을 포함한다.
  • 구체적인 소프트웨어 아키텍처를 위한 템플릿 제공
  • 프로그래밍 언어나 프로그래밍 패러다임에 독립적
• 이디엄 (디자인 패턴의 하위)
  • 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴
  • 주어진 언어의 기능을 사용해 컴포넌트, 혹은 컴포넌트 간의 특정 측면을 구현하는 방법을 서술
  • ex) C++의 COUNT POINTER 은 JAVA에서 유효하지 않다.
• 분석 패턴
  • 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춘다.
  • 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합

패턴과 책임-주도 설계

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

  • 예시
    1. STRATEGY 패턴 : 다양한 알고리즘을 동적으로 교체할 수 있는 역할과 책임의 집합 제공
    2. BRIDGE 패턴 : 추상화의 조합으로 인한 클래스의 폭발적인 증가 문제를 해결하기 위해 역할과 책임을 추상화와 구현의 두 개의 커다란 집합으로 분해함으로써 설계를 확장 가능하게 만든다.
    3. OBSERVER 패턴 : 유연한 통지 매커니즘을 구축하기 위해 객체 간의 결합도를 낮출 수 있는 역할과 책임의 집합을 제공한다.

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

• 패턴의 구성 요소는 클래스가 아니라 “역할”이다.

  • COMPOSITE 패턴에서 하나의 객체가 세 가지 역할을 수행해도 상관없음
  • COMPOSITE 패턴에서 다수의 클래스가 동일한 역할을 구현해도 상관없음

  → 즉, 구체적인 구현 방법을 강조하는 것은 아님!

캡슐화와 디자인 패턴

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

  → 각 디자인 패턴은 특정한 변경을 캡슐화하기 위한 독자적인 방법을 정의

• Movie와 DiscountPolicy의 상속 계층을 합성 관계로 유지하는 것 → STRATEGY 패턴

  • Movie와 DiscountPolicy 사이의 결합도를 낮게 유지 가능

• Movie와 AmountDiscountMovie & PercentDiscountMoive는 상속을 사용하여 캡슐화 → 추상 메서드를 이용하여 변경을 캡슐화

  • TEMPLATE METHOD 패턴
  • 자식들이 추상 메서드를 오버라이딩하여 변하는 부분 구현