Code in Coffee

Object Pool은 객체가 자주 생성/삭제되는 경우 그 비용을 줄이기 위한 디자인 패턴이다. 생성한 객체를 삭제하는 대신, Object Pool이란 곳에 임시로 보관하고 있다가, 새 객체가 필요할 때 객체를 생성하는 대신, Object Pool에서 객체를 꺼내 재활용하는 방식이다. GoF의 디자인 패턴에는 없는 내용이지만 자주 사용할 수 있을 것 같아 넣었다. 구현 Object 아래와 같은 객체가 있다고 하자. // 예시 Object class Object { private: int value; } Object Pool // Object Pool template class ObjectPool { private: std::vector*> pool; // 객체들을 보관하는 벡터 int poolSize; ..

방문자 패턴(Visitor Pattern)은 객체와 기능을 분리할 수 있도록 하는 디자인 패턴이다. 구현 방문자 패턴은 Visitor Concrete Visitor Element Interface Element Client 로 구성된다. Visitor 객체는 Element 객체들을 순회하며 각 Element에 필요한 기능을 수행한다. Visitor Concrete Visitor의 인터페이스로 각 Concrete Visitor는 매개변수가 다르다. // Visitor interface class Visitor { public: virtual void visit(ConcreteElementA* element) = 0; virtual void visit(ConcreteElementB* element) = 0;..

전략 패턴(Strategy Pattern)은 알고리즘을 정의하고 캡슐화하여, 알고리즘의 교체가 필요할 때 알고리즘을 쉽게 변경하거나, 런타임에 알고리즘을 선택하고 변경하도록 하는 디자인 패턴이다. 구현 전략 패턴은 Strategy Concrete Strategy Context 로 구성된다. Strategy Concrete Strategy의 인터페이스이다. // Strategy Interface class IStrategy { public: virtual double calculate(int distance) const = 0; }; Concrete Strategy // Concrete Strategy Classes class ConcreteStrategy1 : public IStrategy { publi..

객체의 상태에 따라 다른 행동을 할 때, 상태 패턴(State Pattern)을 활용해 효율적으로 행동을 구현할 수 있다.컴퓨터 프로그램의 설계에서 자주 쓰이는 개념 중 Finite State Machine(유한 상태 기계)이라는 개념이 있다. Machine은 한 번에 하나의 상태를 가지고, 어떤 이벤트를 통해 다른 상태로 전환될 수 있다.게임 캐릭터나 몬스터의 상태, 애니메이션에서 이런 설계는 자주 볼 수 있다.상태에 따라 다른 행동을 하는 객체를 조건문으로 구현할 수도 있으나 이러한 코드는 유지 보수가 매우 어렵다. switch (state) "draft": state = "moderation" break "moderation": if (currentUser.role == "admin") s..

옵서버 패턴은 자신을 관찰하고 있는 객체에 자신의 상태를 알리는 디자인 패턴이다. 코드의 로직이 다른 값의 변화에 의존하는 경우, 코드는 값을 확인하는 과정이 필요하다. 그러나 변화를 확인하기 위해 계속해서 상태를 확인하는 것은 비효율적이다. 직접 상태를 관찰하는 대신 수동적으로 상태 값을 전달받아 처리하는 패턴을 옵서버 패턴이라 한다. 구현 옵서버 패턴은 Subject Observer 로 구성된다. Subject는 통보를, Observer는 처리를 담당한다. Subject Subject는 객체의 등록, 삭제, 통보를 담당한다. 상태 값을 전달받고 싶어 하는 모든 객체는 Subject에 등록되어 있어야 한다. // 주제(Subject) 인터페이스 class Subject { public: virtual ..

커맨드 패턴(Command Pattern)은 유사한 동작을 하나의 객체로 묶어 실행하는 디자인 패턴이다. 버튼 클래스를 구현한다고 하자. 버튼은 버튼마다 다른 기능이 있다. 저장, 파일 열기, 편집, 적용, 확인 모두 다른 역할을 한다. 그러나 기능에 맞춰 버튼도 여러 클래스를 만들기에는 기능이 너무 많다. 여러 버튼 객체들이 직접 요청을 보내는 대신, 요청을 보내는 인터페이스를 두고, 이 인터페이스가 기능의 요청을 받아 다른 객체로 보낼 수 있다. 구현 커맨드 패턴은 인터페이스 명령 Receiver (수신자) Invoker (호출자) 로 구성된다. Receiver 실제로 작업을 수행하는 객체이다. class Device { public: void On() { ... } void Off() { ... }..

파사드 패턴(Facade Pattern)은 복잡한 서브 시스템의 인터페이스를 제공하는 패턴이다. 객체가 필요한 기능의 클래스를 직접 사용하는 대신, 인터페이스를 구현해 인터페이스를 통해 기능을 사용한다. 구현 파사드 패턴은 Facade Subsystem 으로 구성된다. Facade는 Subsystem의 인터페이스이다. Subsystem Subsystem은 클라이언트가 사용하려 하는 다양한 기능이다. class Inventory { public: bool checkInventory(int productId, int quantity); }; class PaymentProcessor { public: bool processPayment(float amount); }; class Shipping { public..

데코레이터 패턴(Decorator Pattern)은 객체에 동적으로 새로운 기능을 추가하는 패턴이다. 커피 클래스가 있다고 하자. 커피는 우유, 설탕, 얼음, 휘핑 등 다양한 재료를 추가할 수 있다. 커피가 다양한 재료를 하나씩만 추가한다면 커피를 상속받는 자식 클래스를 생성하면 된다. 그러나 우유+설탕과 같이 여러 재료를 넣는 경우를 만든다면, 재료의 양에 따라 수많은 클래스가 필요하고, 새로운 재료를 추가하기도 어렵다. 대신 Decorator 클래스를 구현하고, 클래스를 덮는 클래스를 덮는 클래스를 만드는 식으로 여러 재료를 중첩할 수 있다. 구현 데코레이터 패턴은 Component Decorator Concrete Decorator 로 구성된다. Component Component는 기본이 되는 클..

어댑터 패턴(Adapter Pattern)은 호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 도와준다. A 프로그램은 파일을 hwp 파일로 제공한다. 그러나 B 프로그램은 hwp 파일이 아닌 docx 파일만 열 수 있다. 이런 경우, hwp 파일을 docx로 변환하는 어댑터를 구현하고, B 프로그램이 어댑터가 변환한 파일을 사용하도록 할 수 있다. 구현 어댑터 패턴은 Client Client Interface Service Adapter 로 구성된다. Client는 기존의 프로그램이다. Client Interface는 다른 클래스들이 Client와 작업하도록 따라야 하는 프로토콜이다. Service는 Client가 사용하고 싶은데, 호환되지 않아 사용하지 못하는 클래스이다. Adapter는 S..

싱글턴 패턴(Singleton Pattern)은 객체가 딱 1개만 필요하고, 코드의 다양한 곳에서 접근해야 할 때 사용하는 디자인 패턴이다. 객체지향 프로그래밍의 객체는 빵틀로 찍어내듯 무한히 같은 객체를 생성하는 것이 장점이라고 했다. 하지만 상황에 따라서 객체가 중복되면 오히려 방해되고, 단 하나의 객체만 필요한 경우가 있다. 예를 들어 게임의 BGMManager 객체는 중복으로 생성되면 안 된다. 이처럼 공유 자원에 접근해야 하고 여러 코드가 하나의 자원에 접근하고 유일한 객체가 필요하거나 값이 캐시가 필요할 때 싱글턴 패턴을 사용한다. 구현 싱글턴 클래스는 객체가 1번 생성되어야 한다. 이 기능을 구현하기 위해 생성자를 private으로 설정하고, 생성된 클래스가 없다면 생성을, 있다면 자기 자신..