'디자인 패턴' 패턴 종류

디자인 패턴

소프트웨어 디자인에서 공통적으로 발생하는 문제를 다루는 

보편적이고 반복해서 사용할 수 있는 방법

*코드로 직접 변환될 수 있는 완성된 설계가 아니라

 다양한 상황에 사용될 수 있는 설명이나 템플릿

알고리즘

문제 해결을 위한 처리 절차

 

세 가지 범주의 패턴

 

Creational Patterns (생성 패턴)

객체 생성 메커니즘

객체 생성 패턴, 클래스 생성 패턴으로 분류 됨

Factory, Abstract, Factory, Builder, Prototype, Singleton 패턴 

 

 

Structural Patterns (구조 패턴)

객체들과 클래스들이 커다란 구조를 형성하기 위해 결합될 수 있는 방법을 설명

클래스패턴, 상속의 도움을 받아 추상화를 설명하고 더 유용한 인터페이스를 제공

객체 패턴, 객체들이 크고 더 복잡한 구조를 형성하기 위해 연결되고 구성되는지 설명

Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy 패턴

 

Behavioral Patterns (행위 패턴)

객체 사이의 상호 작용과 관련된 것

객체 간에 공통의 통신 패턴을 파악하고 이러한 패턴을 실현

Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Visitor 패턴  

 

패턴 적용방법

주어진 문제를 이해 -> 세밀한 문제로 분해 -> 특정 문제를 해결하기 위한 디자인 패턴 선택

-> 선택한 디자인 패턴으로 다시 확인 -> 여러 패턴 적용 또는 변형 후 적용

 

Tips

일관적이고 직관적인 클래스 인터페이스 제공

고객은 어떻게 사용하는지만 알면 된다

 

기본 클래스에서 클래스들의 공용 속성을 제공

기본 클래스 인터페이스에 가상 메서드를 배치하는 것은 런타임 다형성의 기본

코드 중복과 불필요한 다운캐스트를 방지

 

클래스의 public 인터페이스에서 구현의 상세를 노출하지 말 것

클래스의 인터페이스가 클래스의 구현 정보를 노출하는 것은 추상화 규약 위반 

 

클래스들 사이의 느슨한 결합을 유지할 것

클래스들은 다른 클래스에 독립적이거나 공용 인터페이스만을 사용해야 함

이해하기 쉽고 사용 유지, 수정이 용이

 

그 외

생성자에서 가상 함수 호출을 피할 것

클래스의 정적 멤버 만이 있는 경우 생성자를 private로 할 것

RTTI, 실행 시 형 식별정보를 통한 가상 함수 식별 권장

객체를 모델링한다면 상속에 대해서는 잊을 것

테스트 주도 개발에 대해 익힐 것

데이터 멤버는 private로 지정

함수에 대해 가장 낮은 접근을 제공하라

의미적으로 같은 일을 할 경우에만 함수를 오버라이드

Factory 메서드를 제공하는 것이 좋음

클래스에 대한 단위 테스트 케이스를 작성

불필요한 임시 객체 생성 금지