빌더 패턴
객체를 구성하는 부분을 먼저 생성, 이를 조합하여 전체 객체 생성
생성할 객체의 종류가 쉽게 추가, 확장 가능
ex) Visual Studio에서 프로젝트를 만들 때 프로젝트 내부에 여러 클래스를 생성한 후 빌드
객체 생성을 위한 부속 객체가 많을 때 사용
생성을 위한 조건이 많을 경우 사용
객체가 절차에 의해 생성되야할 때
Reference : https://dev-youngjun.tistory.com/197
프로토타입 패턴
객체를 복사하여 생성하는 방법
Copy constructor와의 차이
copy constructor는 추상 클래스 상태에서 사용이 불가능
Reference : https://godbolt.org/z/bc15neGf7
Reference : https://stackoverflow.com/a/35939706/8106257
싱글톤 패턴
객체를 N개 이하로만 생성할 수 있도록 보장하는 방법
상속된 객체의 생성 개수를 제한할 수 있음
객체 1개 보장
생성자를 private처리
쉬운 싱글톤
template<class T>
class TSingleton
{
public:
static T& GetInstance()
{
static T instance;
return t;
}
};멀티턴 패턴
여러 개의 인스턴스의 통제된 생성 허용
주로 map을 통한 인스턴스 관리
ex) 다수의 logger를 쉽게 접근
구조 패턴
Adapter 패턴
인터페이스가 서로 다른 시스템간의 연결
기존 시스템의 기능 역시 사용 가능
상속을 통한 재정의, 또는 포함을 통한 사용 둘 다 가능(장단점이 있음)
ex) 상용, 프리 웨어에서 일부 기능만 수정하고자 할 때
데코레이터 패턴
동적으로 기능 추가-삭제
ex) 레벨에 따라 개방되는 skill이 있다고 할 때, 만약 level이 down된다면 개방된 skill은 다시 봉인되야 한다
adapter패턴은 인터페이스만 변경, 데코레이터는 책임, 행동을 변경
퍼사드 패턴
복잡한 서브시스템들의 통합적인 쉬운 인터페이스 제공
composite 패턴
ex) 삼원색을 통해 팔레트의 다양한 색을 만들 수 있음, 이 때 만들어진 색 역시 하나의 색
Element의 그룹을 새로운 Element로 사용
flyweight 패턴
변화하지 않는 객체는 굳이 새로 생성하지 않고 포인터를 공유해 사용
프록시 패턴
ex) 캐시에 최근에 검색한 데이터를 검색
기존 클래스 대신 client의 요청을 대신 처리할 수 있는 대행 클래스를 정의하는 방법
행동 패턴
책임 연쇄 패턴
객체를 체인상에 연결, 특정 요청을 처리하지 못하면 다음 객체에 요청 전달
커맨드 패턴
복잡한 명령을 command라는 추상 클래스를 통해 간접 제어
Adapter와 비슷한 느낌
Reference : https://kotlinworld.com/370
인터프리터 패턴
문자열을 Parsing하여 토큰단위로 분리하는 방법
이터레이터 패턴
반복할 수 있는 대리자를 제공
Mediator 패턴
복잡한 클래스 사이의 관계(m : n)를 단순한 관계(m : 1)로 바꾸는 패턴
Observer 패턴
객체의 상태가 변할 때 그 객체와 연관된 객체들에 알림을 보내는 구조
구독-발행 모델
State 패턴
상태에 따라 행동이 변하는 패턴
상태 전이 조건을 단순화 할 수 있음
FSM에서 사용
Strategy 패턴
동일 목적의 다양한 알고리즘 중 원하는 알고리즘을 선택할 수 있도록 설계한 구조
ex) stl에서 find_if() 함수
함수 포인터
템플릿 메서드 패턴
template사용
Visitor 패턴
One source Multi use에서 동일한 데이터를 여러 표현을 할 수 있도록 만든 구조
다양한 형태로 표현하는 concreteClass
알고리즘과 객체 구조가 분리
디자인 패턴에 대한 개인적 사견
디자인 패턴은 결국 변화하는 것과 변화하지 않는 것을 분리하는 방법에 대한 이야기
그 부분에 집중한다면 이름을 몰라도 사용이 가능하지 않을까?
