Visitor Pattern (방문자 패턴)목적 객체의 속성과 처리(연산)를 분리함으로써 클래스를 수정하지 않고 새로운 연산을 추가할 수 있다. MVC패턴에서 Model과 View를 나눠 놓은것과 비슷하다. UML상에서 Element은 Model과 매핑되고 Visitor는 Controller에 매핑된다. Element에서 Visitor를 accept했을 자기 자신을 Visitor의 visit메소드로 전달 해주는 구조이다. 사용 시나리오 변수 a와 b를 가지고 있는 Element가 있다고 가정한다. Element의 수정없이 더하기 연산과 곱하기 연산을 추가한다. [Element] class Element { public: virtual ~Element(){}; virtual void accept(Visit..
State Pattern (상태 패턴)목적 객체(Context)가 가질 수 있는 (유한한)상태를 추상화하여 런타임에 상태를 유연하게 변경하도록 한다. UML상 전략패턴과 거의 동일하지만 실제로 다른점은 전략패턴의 경우 사용하는 쪽에서 직접 알고리즘을 교체하지만 상태패턴은 사용하는 쪽에서 내부의 상태가 어떻게 바뀌는지 모른다. FSM(Finite State Machine)을 구현하기에 적합한 패턴이다. 사용 시나리오 전구 상태를 표현하는 시스템이 있다. 전구의 상태는 켜짐과 꺼짐 두개가 존재하며 on/off 버튼을 통해 상태가 변한다. 꺼진 상태 -> on 버튼 -> 켜짐 -> on 버튼 -> 동작 안함 켜진 상태 -> off 버튼 -> 꺼짐 -> off 버튼 -> 동작 안함 [Context] class ..
Memento Pattern (메멘토 패턴) 목적 캡슐화를 위배하지 않은 채 객체의 내부 상태를 저장하고 되돌아올 수 있도록 한다. 사용 시나리오 텍스트 에디터를 개발중에 있다고 가정하자 텍스트 에디터에 ctrl Z입력시 이전에 입력했던 텍스트로 상태를 불러오는 기능을 추가한다. [Memento] class InputMemento { public: InputMemento(string& input) { this->input = input; } string getState() { return this->input; } private: string input; }; [Originator] class InputOriginator { public: void setCurrentInput(string input) {..
Mediator Pattern (중재자 패턴) 목적 각각의 객체들(colleague)끼리 서로를 직접 참조하지 않고 mediator(중재자)를 통해 메세지를 주고 받는다. 각각의 객체들은 서로에 대한 정보는 전혀 모르기 때문에 커플링이 느슨하게 한다. 사용 시나리오 스마트폰이 없던 시절 문자로 단체일정을 잡기 위해서는 아래의 그림과 같이 개개인에게 연락을 했어야 했다. 스마트폰의 등장이후로 단체톡방(Mediator)을 만들어서 메세지(일정)를 보내면 된다 [Mediator] class Meditator { public: virtual ~Meditator() {} void addColleague(Colleague* collegue) { this->collegues.push_back(collegue); } ..
Command Pattern (명령 패턴) 목적 Client가 어떤 기능에 대한 요청을 할 때 요청을 직접 호출하지 않고 요청자체를 캡슐화한다. 명령 패턴의 핵심은 연산을 실행하는 데 필요한 인터페이스를 선언해 놓은 Command 추상 클래스이다. Client입장에서는 필요한 구체화된 Command만 설정해주면 된다. 사용 시나리오 Iot 허브가 있고 허브에서 연결된 things를 제어한다고 가정한다. Iot허브는 Invoker가 되고 things는 Receiver가 된다. things 각각의 명령어를 command로 구체화 한다. 해당 예에서는 IoT기능이 있는 IotTV를 Command패턴을 통해 제어하는 예이다. [Receiver] class IotTV { //Receiver public: void..
Chain of Responsibility Pattern (책임 연쇄 패턴) 목적 Request를 보내는 객체와 받는 객체들 간의 결합도를 없애기 위한 패턴이다. 하나의 Request에 대한 처리가 여러 객체에서 가능하다. 현재 객체에서 처리했거나 혹은 처리하지 못한 request를 다음 객체로 넘김으로써 다른 객체에서 Request를 처리할 수 있는 기회를 준다. 이러한 방식은 링크드 리스트 자료구조와 유사하다. 결론적으로 하나의 Request에대한 여러 처리방식을 유연하게 연결(추가)할 수 있다. 사용 시나리오 어떤 API를 사용하기 위해서 인증절차를 거쳐야 한다. 인증 요청은 id값과 token값으로 한다. 인증과정 절차는 id를 확인하는 과정과 token을 확인하는 과정 총 두가지이다. [Requ..
행동 패턴에는 다음과 같이 11가지 패턴이 존재한다. Chain of Responsivility Command Interpreter Iterator Mdiator Memento Observer State Strategy Template Method Visitor 행동 패턴은 테스크의 처리를 어떤 객체가 할것인지에 대해 다룬다.
Template Method Pattern (C++) 목적 객체의 연산에는 알고리즘 뼈대만(템플릿) 정의하고 각 단계에서 수행하는 구체적인 처리들은 서브클레스에게 위임한다. 코드의 공통적인부분과 아닌 부분을 구별하여 코드 중복을 제거하고 hook연산을 추가하여 확장성을 높인다. 사용 시나리오 파일 뷰어를 만든다고 가정한다. 파일뷰어는 doc,txt등 여러 확장자의 파일들을 보여줄 수 있다. 파일을 보여줄 때 내부적으로 항상 open -> view -> save log과정을 거친다. [AbstractClass] class FileViewer { public: void viewFile() { //템플릿 메소드 역할을 하는 함수 open(); view(); saveLog(); hookFunc(); } pro..
Strategy Pattern (C++) 목적 동일 계열의 알고르즘군을 묶어서 인터페이스를 통해 제공하고 클라이언트 입장에서 이를 상호교환이 가능하도록 만든다. 상황에 맞게 유연하게 알고리즘 교체를 목적으로 한다. 사용 시나리오 리눅스에서 여러 I/O 스케줄링 방법이 존재한다. (알고리즘 군이 될 FIFO, Round Robin, Shortest Remaining Time 예제에서는 세개만 사용) 오너 사용자가 스케줄링 방법을 변경할 수 있도록 시스템을 만든다. [Strategy] 인터페이스 역할을 하는 Base strategy를 정의한다. class Scheduler { public: virtual void doSchedule() = 0; }; [ConcreteStrategy] Base strategy..
Observer Pattern (감시자 패턴)목적어떤 객체의 상태가 변할 때 그 객체의 변화를 통지받기(Notify)를 원하는 다른 객체들이(옵저버) 그 변화를 통지받을 수 있도록 한다.통지는 각각의 옵저버들이 변화된 객체로부터 콜백(callback)을 받는다. 사용 시나리오1. 시간정보를 가지고 있는 클래스가 있다.2. 디지털 시계 위젯과 아날로그 시계 위젯이 시간정보 객체로부터 시간의 변할때마다 통지를 받고싶다.3. 시간이 변할 때마다 시간정보 클래스에서 옵저버객체들에게 변화를 알린다. [Subject]시간 정보를 가지고 있는 클래스이며 옵저버의 등록을 받아 옵저버를 리스트로 저장해 두었다가 시간이 변할 때 알려 준다. class ClockTimer { public: void RegisterObser..
