[디자인패턴] 디자인 패턴 설명

디자인패턴(Design Patterns)

소프트웨어 개발에서 자주 반복되는 문제들을 해결하기 위해 만들어진 재사용 가능한 코드 설계 방법입니다. 즉, 소프트웨어 설계 시 발생할 수 있는 문제를 효율적으로 해결하기 위한 설계의 모범 사례라고 할 수 있습니다.

장점

• 개발자간의 원활한 소통
• 소프트웨어 구조 파악이 용이
• 재사용을 통한 개발 시간 단축
• 설계 변경 요청에 대한 유연한 대처

단점

• 객체지향 설계에 대한 깊은 이해도가 필요
• 간단한 문제에 대해 디자인 패턴을 적용하는 것이 오히려 더 복잡하고 비효율적일 수 있습니다.
• 모든 문제에 대해 디자인 패턴을 적용하는 것은 적절하지 않습니다.

디자인 패턴의 3가지 대분류

생성패턴 (Creational Pattern)

객체 생성에 관련된 패턴으로, 생성절차를 추상화하는 패턴입니다. 객체가 생성되는 방식을 기본적인 형태에서 분리하여 코드의 유연성을 높입니다. 생성패턴은 시스템이 어떤 구체 클래스를 사용하는지에 대한 정보를 캡슐화합니다. 이러한 패턴을 사용하면 코드의 유연성과 재사용성을 높일 수 있습니다.

1. 싱글톤 패턴 (Singleton Pattern)

• 목적: 클래스의 인스턴스를 단 하나만 생성하도록 보장하고, 그 인스턴스에 접근할 수 있는 전역 접근점을 제공합니다.
• 사용 예: 설정 관리, 로깅, 데이터베이스 연결
• 특징:
  • 생성자의 호출을 제한하여 하나의 객체만 유지
  • 전역 상태 관리가 필요할 때 유용

---

2. 팩토리 메서드 패턴 (Factory Method Pattern)

• 목적: 객체 생성 코드를 서브클래스에서 정의하여 객체 생성 방식을 캡슐화합니다.
• 사용 예: 다양한 타입의 객체를 생성해야 하는 경우
• 특징:
  • 객체 생성의 책임을 하위 클래스에 위임
  • 클라이언트 코드와 객체 생성 로직의 분리

---

3. 추상 팩토리 패턴 (Abstract Factory Pattern)

• 목적: 관련되거나 의존적인 객체들의 가족(Family)을 생성하기 위한 인터페이스를 제공합니다.
• 사용 예: 서로 다른 플랫폼에서 호환 가능한 객체 생성
• 특징:
  • 제품군(Product Family)의 객체 생성을 일관성 있게 보장
  • 구체적인 클래스에 의존하지 않고 객체 생성

---

4. 빌더 패턴 (Builder Pattern)

• 목적: 복잡한 객체를 단계별로 생성할 수 있도록 합니다. 같은 생성 절차에서 서로 다른 표현을 생성할 수 있습니다.
• 사용 예: 복잡한 초기화가 필요한 객체 생성
• 특징:
  • 객체 생성 과정을 세분화하여 유연성 제공
  • 빌더 클래스가 객체 생성 과정을 캡슐화

---

5. 프로토타입 패턴 (Prototype Pattern)

• 목적: 기존 객체를 복사하여 새로운 객체를 생성합니다.
• 사용 예: 비용이 많이 드는 객체 생성 시
• 특징:
  • 객체 복사를 통해 성능 최적화
  • 깊은 복사와 얕은 복사로 구현 가능

---

6. 스태틱 팩토리 메서드 (Static Factory Method)

• 목적: 객체 생성 메서드를 정적 메서드로 제공하여 간단히 객체를 생성합니다.
• 사용 예: 특정 조건에 따라 객체 생성 로직을 간단히 처리하고자 할 때
• 특징:
  • 생성자 호출보다 더 직관적인 방식 제공
  • 여러 유형의 객체 생성을 유연하게 처리

 

구조 패턴 (Structural Pattern)

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴입니다. 서로 다른 인터페이스를 가진 두 개의 객체를 함께 사용하거나, 객체들을 서로 묶어 새로운 기능을 제공하는 등의 역할을 합니다. 이를 통해 객체 간의 상호작용을 간소화하고, 시스템의 유연성과 확장성을 높일 수 있습니다.

 

1. 어댑터 패턴 (Adapter Pattern)

• 목적: 호환되지 않는 인터페이스를 가진 두 클래스가 함께 작동할 수 있도록 중간에 변환기를 제공.
• 사용 예: 새로운 시스템을 기존 시스템과 연결하거나, 외부 라이브러리 사용 시.
• 특징:
  • 인터페이스의 차이를 변환
  • 클래스 어댑터와 객체 어댑터 방식으로 구현 가능

---

2. 브리지 패턴 (Bridge Pattern)

• 목적: 추상화와 구현을 분리하여 독립적으로 확장할 수 있도록 합니다.
• 사용 예: 플랫폼 독립적인 기능 제공, UI 요소와 데이터 처리 분리.
• 특징:
  • 상속 대신 구성(Composition)을 활용
  • 추상화와 구현 계층을 분리하여 확장성 증대

---

3. 컴포지트 패턴 (Composite Pattern)

• 목적: 객체를 트리 구조로 구성하여 부분-전체 계층을 나타냅니다. 개별 객체와 복합 객체를 동일하게 처리할 수 있습니다.
• 사용 예: 파일 시스템, 그래픽 UI 요소
• 특징:
  • 단일 객체와 복합 객체를 동일하게 다룸
  • 재귀적인 구조로 설계

---

4. 데코레이터 패턴 (Decorator Pattern)

• 목적: 객체에 동적으로 새로운 기능을 추가할 수 있도록 합니다.
• 사용 예: 텍스트에 스타일 적용, 네트워크 데이터 처리 시 계층적 기능 추가.
• 특징:
  • 기존 클래스 수정 없이 기능 확장
  • 중첩된 데코레이터로 다양한 조합 가능

---

5. 퍼사드 패턴 (Facade Pattern)

• 목적: 복잡한 서브시스템에 대한 단순화된 인터페이스를 제공합니다.
• 사용 예: 라이브러리나 서브시스템의 복잡한 API를 간소화.
• 특징:
  • 클라이언트와 서브시스템 간의 결합도 감소
  • 단일 진입점을 제공하여 사용성을 향상

---

6. 플라이웨이트 패턴 (Flyweight Pattern)

• 목적: 공유 가능한 객체를 사용하여 메모리 사용을 줄입니다.
• 사용 예: 대량의 객체를 생성 및 관리해야 할 때, 그래픽 렌더링의 텍스처 관리.
• 특징:
  • 내부 상태와 외부 상태로 객체를 나누어 관리
  • 메모리 최적화에 유리

---

7. 프록시 패턴 (Proxy Pattern)

• 목적: 다른 객체에 대한 접근을 제어하기 위해 대리 객체를 제공합니다.
• 사용 예: 원격 객체 호출, 지연 초기화, 접근 제어.
• 특징:
  • 실제 객체에 대한 접근을 제어
  • 보호 프록시, 가상 프록시, 캐싱 프록시 등 다양한 방식으로 구현 가능

 

행동 패턴

행동 패턴(Behavioral Pattern) : 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴입니다. 즉, 객체의 행동 패턴에 초점을 맞춥니다. 이러한 패턴은 객체 간의 통신 방법을 정의하거나, 동작을 캡슐화하여 유연한 설계를 가능하게 합니다.

 

1. 책임 연쇄 패턴 (Chain of Responsibility Pattern)

• 목적: 요청을 처리할 수 있는 기회를 여러 객체에게 제공하며, 처리 객체를 명시적으로 지정하지 않습니다. 요청을 객체의 체인을 따라 전달합니다.
• 사용 예: 지원 요청 처리 시스템, 이벤트 핸들링.
• 특징:
  • 요청 처리 객체의 유연한 추가 및 제거
  • 요청 처리 순서를 체인 구조로 구현

---

2. 커맨드 패턴 (Command Pattern)

• 목적: 요청 자체를 캡슐화하여 요청을 큐(queue)로 저장하거나 나중에 실행할 수 있도록 합니다.
• 사용 예: 실행 취소/재실행 기능, 작업 예약.
• 특징:
  • 요청, 수신자, 실행자 간의 결합도를 낮춤
  • 실행 취소 및 명령 기록 가능

---

3. 인터프리터 패턴 (Interpreter Pattern)

• 목적: 언어의 문법 표현을 정의하고, 이를 사용하여 언어를 해석합니다.
• 사용 예: SQL 파서, 수식 계산기.
• 특징:
  • 특정 문법이나 언어를 처리하는 클래스 계층 생성
  • 표현식의 해석 논리를 객체화

---

4. 이터레이터 패턴 (Iterator Pattern)

• 목적: 집합 객체의 내부 표현을 노출하지 않고, 그 요소들에 순차적으로 접근할 수 있도록 합니다.
• 사용 예: 컬렉션 탐색, 파일 탐색.
• 특징:
  • 컬렉션의 구조와 관계없이 동일한 방식으로 접근
  • 컬렉션과 이터레이터를 분리하여 유연성 제공

---

5. 중재자 패턴 (Mediator Pattern)

• 목적: 객체들 간의 상호작용을 캡슐화하는 중재자 객체를 정의하여 객체 간의 의존성을 줄입니다.
• 사용 예: 채팅 시스템, UI 요소 간의 통신.
• 특징:
  • 객체들이 서로 직접 통신하지 않고 중재자를 통해 통신
  • 복잡한 객체 간 상호작용을 단순화

---

6. 메멘토 패턴 (Memento Pattern)

• 목적: 객체의 상태를 저장하고, 나중에 복원할 수 있도록 합니다.
• 사용 예: 실행 취소 기능, 게임 저장/로드.
• 특징:
  • 객체 상태의 캡슐화된 저장과 복원
  • 저장된 상태를 외부에서 수정할 수 없음

---

7. 옵저버 패턴 (Observer Pattern)

• 목적: 객체 상태의 변화를 관찰하고, 변화가 있을 때 관련 객체에 알림을 전달합니다.
• 사용 예: 이벤트 시스템, 데이터 바인딩.
• 특징:
  • 주체와 관찰자 간의 느슨한 결합
  • 다수의 관찰자에게 동일한 업데이트 전달 가능

---

8. 상태 패턴 (State Pattern)

• 목적: 객체의 내부 상태에 따라 동작을 변경할 수 있도록 상태를 캡슐화합니다.
• 사용 예: 게임 캐릭터 상태(공격, 방어), 문 상태(열림, 닫힘).
• 특징:
  • 상태 전환 논리를 상태 객체로 분리
  • 상태 추가 및 변경이 용이

---

9. 전략 패턴 (Strategy Pattern)

• 목적: 알고리즘을 캡슐화하여 런타임에 동적으로 알고리즘을 선택할 수 있도록 합니다.
• 사용 예: 정렬 알고리즘, 경로 탐색 알고리즘.
• 특징:
  • 서로 다른 알고리즘을 쉽게 교체 가능
  • 클라이언트 코드와 알고리즘 구현 분리

---

10. 템플릿 메서드 패턴 (Template Method Pattern)

• 목적: 상위 클래스에서 알고리즘의 골격을 정의하고, 하위 클래스에서 세부 사항을 구현하도록 합니다.
• 사용 예: 데이터 처리 파이프라인, 게임 로직.
• 특징:
  • 알고리즘의 재사용성과 유연성 제공
  • 특정 단계는 하위 클래스에서 오버라이딩 가능

---

11. 방문자 패턴 (Visitor Pattern)

• 목적: 객체 구조에 새로운 동작을 추가하면서, 객체의 구조를 변경하지 않습니다.
• 사용 예: 객체 구조 탐색 및 처리, XML 파싱.
• 특징:
  • 객체의 데이터를 외부 클래스로 분리하여 새로운 연산 추가 용이
  • 객체 구조와 동작 간의 분리