디자인 패턴이란?

일종의 설계 기법이며, 설계 방법이다.

• 디자인 패턴은 소프트웨어 디자인 과정에서 자주 발생하는 문제들에 대한 전형적인 해결책이다.
• GoF(Gang of Four)
  • 현재 사용되는 기본적인 23가지 디자인 패턴을 정리한 아저씨들
  • 에릭 감마, 존 블리시디스, 랄프 존슨, 리처드 헬름

디자인 패턴의 분류

• 디자인 패턴은 복잡성, 상세도 및 설계 중인 전체 시스템 등의 적용 범위에 따라 분류된다.
• 모든 패턴은 패턴의 의도 또는 목적에 따라 분류할 수 있다.

이디엄(idiom)

• 가장 기본적인 하위 레벨의 패턴. (low-level pattrern)
• 일반적으로 하나의 프로그래밍 언어에만 해당함.
• 이디엄은 주어진 언어의 기능을 사용해서 컴포넌트들 혹은 컴포넌트들 간 관계의 특정 측면을 구현하는 방법을 서술한다.

아키텍처 패턴(Architecture Pattern)

• 가장 보편적인 상위 수준 패턴(high-level pattern)
• 다른 패턴들과 달리 아키텍처 패턴은 애플리케이션 전체의 구조(아키텍처)를 설계하는 데 사용할 수 있다.
• 생성 패턴
  • 기존 코드를 재활용하고 유연성을 증가시키는 객체 생성 매커니즘을 제공한다.
• 구조 패턴
  • 구조를 유연하고 효율적으로 유지하면서 객체와 클래스를 더 큰 구조로 조합하는 방법
• 행동 패턴
  • 객체 간의 효과적인 의사소통과 책임 할당을 처리한다.

---

좋은 디자인의 특징

• 코드 재사용
  • 소프트웨어 개발 시 가장 중요한 두 가지 지표는 비용과 시간이다.
  • 따라서 코드 재사용은 개발 비용을 줄이는 가장 일반적인 방법의 하나다.
  • 이 개념은 이론상으론 좋으나 새로운 상황에서 기존 코드를 작동하게 할 때는 여러가지 문제가 있다. 컴포넌트 간의 단단한 결합이나 인터페이스 대신 구상 클래스들에 대한 의존관계, 하드코딩 된 작업 등과 같은 요인들 때문에.
  • 코드 재사용과 유연성에 대한 에릭 감마의 의견
    • 재사용을 3가지 수준으로 이해한다.
      • 낮은 수준의 재사용
        • 클래스들을 재사용한다.
        • 클래스 라이브러리, 컨테이너 및 컨테이너/반복자와 같은 어떤 클래스 팀이 있다.
      • 중간 수준의 재사용
        • 디자인 패턴이 이 수준에 속한다.
        • 디자인 패턴은 프레임워크보다 더 작고 추상적이다
        • 패턴은 몇 개의 클래스들이 서로 어떻게 관련되어 있으며, 상호 작용할 수 있는지에 대한 상세한 설명이다.
        • 클래스 → 패턴 → 프레임워크로 이동할 수록 재사용 수준이 높아진다.
        • 중간 수준 계층의 좋은 점은 패턴이 종종 프레임워크보다 덜 위험한 방식의 재사용을 제공한다.
        • 프레임워크를 구축하는 것은 위험이 높을 뿐 아니라 상당한 투자가 들어가는 일이기 때문.
        • 패턴을 사용할 시 구상 코드와 관계없이 디자인 아이디어들과 개념들을 재사용할 수 있다.
      • 최고 수준의 재사용
        • 프레임워크
        • 프레임워크는 문제를 해결하기 위한 핵심 추상화들을 식별한 후 해당 추상화들을 클래스들로 표현하고 그들 사이의 관계들을 정의한다.
        • 프레임워크는 일반적으로 단일 클래스보다 입자들이 크다. 또한 프레임워크에 연결할 때는 어딘가를 서브클래싱하여 연결한다.
        • 헐리우드 원칙(전화하지 마, 전화할게)을 사용한다.
        • 프레임워크는 사용자 지정 행동을 정의할 수 있도록 해주고 어떤 작업을 수행할 차례가 되면 호출할 것이다.
• 확장성
  • 변화는 프로그래머 삶에서 유일하게 변하지 않는 것.
  • 여러가지 이유에 의해 변경점이 생기고 변화에 유연하게 대응할 수 있어야한다.

---

디자인 원칙

1. 변화하는 내용을 캡슐화 하라

앱에서 변경되는 부분들을 식별한 후 변하지 않는 부분들과 구분해라

• 해당 원칙의 가장 큰 목적은 변화로 인해 발생하는 결과를 최소화 하는 것이다.
• 메서드 수준에서의 캡슐화
  • 특정 비즈니스 로직을 (검증로직 같은거) 분리
• 클래스 수준에서의 캡슐화
  • 간단한 작업을 수행했던 메서드에 점점 많은 책임이 추가될 수 있다.
  • 이렇게 추가된 행동들은 고유의 도우미 필드와 메서드를 동반하곤 하는데 이럴 때 클래스를 분리하면 코드는 명확하고 간단해진다.

2. 구현이 아닌 인터페이스에 대해 프로그래밍 하라

구현이 아닌 인터페이스에 대해 프로그래밍 하라. 또한, 구상클래스에 의존하는 대신 추상화에 의존하라

1. 한 객체가 다른 객체에 무엇을 필요로 하는지 확인
2. 새 인터페이스 또는 추상 클래스에서 이러한 메서드들을 설명
3. 다른 객체에 의존하는 클래스가 이 인터페이스를 구현
4. 두 번째 클래스를 구상 클래스가 아닌 이 인터페이스에 의존

3. 상속보다 합성을 사용하라

• 상속을 사용할 경우 야기되는 문제점
  • 자식 클래스는 상위 클래스의 인터페이스를 줄일 수 없다.
  • 메서드들을 오버라이드할 때 새 행동이 기초 행동과 호환되는지 확인해야한다.
  • 상속은 부모 클래스의 캡슐화를 깨뜨린다.
  • 자식 클래스들은 부모 클래스들과 밀접하게 결합한다.
  • 상속을 통해 코드를 재사용하려고 하면 병렬 상속 계층구조들이 생성될 수 있다.
• 상속에는 합성이라는 대안이 있다.
  • 상속은 클래스 간의 ‘나는 무엇의 ~이다’ 라는 관계를 나타내지만 합성은 ‘~을/를 가진다’ 관계를 나타낸다.
  • 해당 원칙은 집합관계에도 적용될 수 있다.
    • 집합관계는 합성의 더욱 완화된 변형으로 한 객체가 다른 객체에 대한 참조를 가질 수는 있지만 이 객체의 수명주기는 관리하지 않는다.
    • 예를 들어 자동차는 운전자를 가진다. 그러나 운전자는 차를 사용하지 않거나 차 없이(가진다의 반대) 그냥 걸을 수도 있다.