[객체지향설계] GoF(Gang of Four) 디자인 패턴(프로토타입, 추상 팩토리, 어댑터, 브리지, 복합체, 퍼사드, 프록시)

Prototype Pattern(프로토타입)

 

프로토타입은 생성 패턴의 일종으로 객체의 복사를 위한 패턴이다.

기존에는 객체를 복사하기 위해 그 프로퍼티들을 모두 복사하여, 새롭게 객체를 구성하여야 했다. 이러한 방식은 코드로 하나하나 짜기에 귀찮다. 또한 클래스 내부의 Private로 선언된 프로퍼티들이 있다면 완벽하게 복사해낼 수 없다.

 

출처 : https://refactoring.guru/ko/design-patterns/prototype

 

 

프로토타입 패턴은 이러한 문제를 해결하기 위해 복사 프로세스를 객체들에게 위임한다. 즉, 모든 객체들이 공통적으로 가지고 있는 "clone" 메서드를 만드는 것이다.

 

모든 객체들이 clone 메서드를 가지게 된다면, 각 객체의 private 멤버에 접근할 수 있게된다. 이 말이 의미한 것은 곧, 완벽하게 해당 객체에서 새로운 객체로 복사가 가능하다는 것이다.

 

이렇게 복사를 지원하는 객체를 프로토타입이라고 한다.

 

 

프로토타입 패턴의 구조

 

 

출처 : https://refactoring.guru/ko/design-patterns/prototype

 

 

 

구조는 크게 어렵지 않다. Shape는 clone()이라는 공통 메서드를 정의한다. 그리고 이 Shape의 상속을 받는 Rectangle과 Circle은 이 clone 메서드를 똑같이 가진다. 이를 통해 Rectangle과 Circle은 자기 자신의 객체를 복제할 수 있게 되는 것이다.

 

 

 

 

 

 

프로토 타입을 C++로

 

 

Color 클래스

enum class Color {
    kRed,
    kGreen,
    kBlue,
    kWhite,
    kBlack,
};

std::string ColorToString(Color color) {
    switch (color) {
        case Color::kRed:
            return "Red";
        case Color::kGreen:
            return "Green";
        case Color::kBlue:
            return "Blue";
        case Color::kWhite:
            return "White";
        case Color::kBlack:
            return "Black";
        default:
            return "Unknown";
    }
}

 

 

Shape 클래스(프로토타입<interface>)

class Shape {
 public:
  Shape(Color color) : color_(color) {}
  virtual Shape* Clone() const = 0;
  virtual std::string ToString() const = 0;

 protected:
  const Color color_;
};

 

 

Rectangle 클래스(프로토타입 구현체1)

class Rectangle : public Shape {
 public:
  Rectangle(Color color, int width, int height)
      : Shape(color), width_(width), height_(height) {}
  Shape* Clone() const override {
    return new Rectangle(color_, width_, height_);
  }
  std::string ToString() const override {
    return "Color: " + ColorToString(color_) +
           ", Width: " + std::to_string(width_) +
           ", Height: " + std::to_string(height_);
  }

 private:
  const int width_;
  const int height_;
};

 

 

Circle 클래스(프로토타입 구현체2)

class Circle : public Shape {
  public:
  Circle(Color color, int radius) : Shape(color), radius_(radius) {}
  Shape* Clone() const { return new Circle(color_, radius_);}
  std::string ToString() const {
    return "Color: " + ColorToString(color_) + ", Radius: " + 
    std::to_string(radius_);
  }
  private:
  const int radius_;
};

 

 

Main 클래스

int main() {
  Shape* shape1 = new Rectangle(Color::kWhite, 3, 2);
  Shape* shape2 = shape1 -> Clone();

  Shape* shape3 = new Circle(Color::kRed, 5);
  Shape* shape4 = shape3 -> Clone();

  std::cout << shape1 << " : " << shape1 -> ToString() << std::endl;
  std::cout << shape2 << " : " << shape2 -> ToString() << std::endl;
  std::cout << shape3 << " : " << shape3 -> ToString() << std::endl;
  std::cout << shape4 << " : " << shape4 -> ToString() << std::endl;
}

 

 

실행 결과

0xfb9b10 : Color: White, Width: 3, Height: 2
0xfb9b28 : Color: White, Width: 3, Height: 2
0xfb9b40 : Color: Red, Radius: 5
0xfb9b58 : Color: Red, Radius: 5

 

 

🔲 C++에서의 prototype은 함수 오버로딩과 함수 오버라이딩의 과정으로 이루어진다.

 

🔲 Shape의 virtual ... Clone() 을 통해서 각 Rectangle, Circle 중 하나의 Clone()이 실행된다.

 

🔲 출력 결과 Clone()을 통해 서로 다른 객체가 생성되었으며, 그 내용물은 같다는 것을 알 수 있다.

 

 

---

 

 

 

 

 

Abstract Factory Pattern(추상 팩토리)

 

 

추상 팩토리는 관련 객체들의 구상 클래스들을 지정하지 않더라도, 관련 객체의 모음을 선택할 수 있는 생성 패턴이다.

 

만약에 주문자(Client) 빅토리안식 의자, 소파, 커피 테이블을 구매하고 싶을 때, 굳이 구체적으로 빅토리안 식 의자, 빅토리안 식 소파, 빅토리안식 커피 테이블을 주문하지 않아도 된다.

 

결국 주문자는 어느 회사(팩토리)에서 구매할 것인지 정해야 한다. 빅토리안식으로 각 제품을 판매하는 빅토리안 팩토리, 아르데코 식으로 각 제품을 판매하는 아르데코식 팩토리, 마찬가지로 현대식 팩토리가 있다고 하자. 주문자는 빅토리안 팩토리에서의 제품만을 원한다면 구체 팩토리로 빅토리안 팩토리를 선택하면 된다.

 

자 이제 다시 그 의미를 짚어보자. 추상 팩토리란, 관련 객체(의자, 소파, 커피 테이블)들의 구상 클래스(빅토리안식 의자, 빅토리안 식 소파, ...)를 지정하지 않더라도, 관련 객체의 모음(빅토리안 식 의자, 빅토리안 식....)을 선택할 수 있는 생성 패턴이다.

 

다시말해, 연관성 있는 제품 군이 여러개 있을 경우 이를 묶어 추상화하고, 구체적인 상황이 주어질 때 팩토리 객체에서 집합으로 묶은 객체군을 구현하는 패턴이라는 것이다.

 

 

 

 

 

추상 팩토리 패턴의 특징

 

 

추상 팩토리를 사용하는 시기

 

1️⃣ 제품의 구체 클래스에 의존하고 싶지 않을 때(여러 제품군이 있을 경우)

 

2️⃣ 시스템 상에서 하나의 제품 군으로 설정해야 하는 경우(예를 들어 애플 제품 군으로 통일 해야할 때)

 

3️⃣ 구현 부분 대신 인터페이스 부분만 보여주고 싶은 경우

 

---

 

추상 팩토리의 장점

 

1️⃣ 클라이언트 코드와의 결합성을 낮춤

 

2️⃣ 제품을 쉽게 대체 가능

 

---

 

추상 팩토리의 단점

 

1️⃣ 만들어야 하는 클래스가 많아져, 복잡도가 증가

 

2️⃣ 추상 클래스 로직 자체를 바꾸어야 하는 경우가 생김

 

 

 

 

 

 

추상 팩토리 패턴의 구조

 

 

추상 팩토리 패턴의 코드를 이해하기 위해서는 그 구조를 명확히 알고 있어야 한다.

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/abstract-factory

 

 

 

🔲 AbstractFactory : 추상 팩토리로 추상 제품들을 생성하기 위한 여러 메서드들의 집합을 선언한다.

 

🔲 ConcreteFactory : 구상 팩토리로 추상 팩토리의 생성 메서드들을 구현한다.

 

🔲 AbstractProduct : 추상 제품으로 각 타입의 제품들을 추상화한 인터페이스이다.

 

🔲 ConcreteProduct(ProductA, ProductB) : 각 타입의 제품 구현체들이다.

 

🔲 Client : 추상화된 인터페이스만을 이용하여 제품을 만든다.

 

 

각 ConcreteFactory(구상 팩토리)는 구체적인 공장으로, 제품 군의 유형에 따라 나뉜다. 예를 들어, 빅토리안식 공장, 아르데코식 공장, 현대식 공장등이 이러한 ConcreteFactory에 속한다.

 

ConcreteFactory 를 통해서 ConcreteProduct (제품 구현체)를 만들 수 있다. ConcreteProduct는 그 인터페이스로 AbstractProduct 를 따르는 것 뿐이다.

 

 

 

 

 

추상 팩토리 패턴을 C++로

 

 

추상 팩토리(AbstractFactory)

// 추상 팩토리
class FurnitureFactory {
 public:
  virtual Chair* OrderChair() const = 0;
  virtual Table* OrderTable() const = 0;
};

 

 

구상 팩토리(ConcreteFactory)

// 구상 팩토리1
class ModernFactory : public FurnitureFactory {
 public:
  // 구현체를 생성하는 메서드를 지님. 반환 타입은 AbstractProduct
  Chair* OrderChair() const override {
    return new ModernChair();
  }

  Table* OrderTable() const override {
    return new ModernTable();
  }
};

// 구상 팩토리2
class AntiqueFactory : public FurnitureFactory {
 public:
  Chair* OrderChair() const override {
    return new AntiqueChair();
  }

  Table* OrderTable() const override {
    return new AntiqueTable();
  }
};

 

 

 

추상 제품(AbstractProduct)

// 추상 제품1
class Chair {
 public:
  virtual std::string ToString() const = 0;
};

// 추상 제품2
class Table {
 public:
  virtual std::string ToString() const = 0;
};

 

 

 

구상 제품(ConcreteProduct)

// 구현체 1
class ModernChair : public Chair {
 public:
  std::string ToString() const override {
    return "Modern Chair";
  }
};

// 구현체 2
class ModernTable : public Table {
 public:
  std::string ToString() const override {
    return "Modern Table";
  }
};

// 구현체 3
class AntiqueChair : public Chair {
 public:
  std::string ToString() const override {
    return "Antique Chair";
  }
};

// 구현체 4
class AntiqueTable : public Table {
 public:
  std::string ToString() const override {
    return "Antique Table";
  }
};

 

 

실행 메서드 및 main 함수

void OrderAndPrint(FurnitureFactory* factory) {
  Chair* chair = factory->OrderChair();
  Table* table = factory->OrderTable();

  std::cout << "Table: " << table->ToString() << ", Chair: " << chair->ToString() << std::endl;
}

int main() {
  ModernFactory modern_factory;
  AntiqueFactory antique_factory;

  OrderAndPrint(&modern_factory);
  OrderAndPrint(&antique_factory);

  return 0;
}

 

 

실행 결과

Table: Modern Table, Chair: Modern Chair
Table: Antique Table, Chair: Antique Chair

 

---

 

🔲 추상 팩토리에서 들어오는 구체 팩토리의 타입에 따라 구체 팩토리의 메서드가 실행된다.

 

🔲 구체 팩토리의 메서드를 실행시킴으로써, 각 제품군에 일치하는 제품(구현체)를 생성할 수 있다.

 

🔲 구체 팩토리에서 실행되는 메서드에서 반환되는 타입은 각 제품의 추상 제품(Abstract Product)이다.

 

 

---

Structural Design Patterns(구조 패턴)

 

 

구조 패턴은 클래스와 객체를 더욱 큰 구조로 만들기 위해서 사용한다. 구조 패턴의 종류는 아래와 같다.

 

• Adapter
• Bridge
• Composite
• Decorate
• Facade
• Flyweight
• Proxy
• ...

 

 

 

Adapter Patterns(어댑터 패턴)

 

 

어댑터 패턴을 쉽게 이해해 보자면, 전자기기 단자를 호환하게 해주는 어댑터를 생각하면 된다. 즉, 어댑터는 해외여행을 갈때 사용할 수 없는 콘센트와 나의 전자기기를 연결해주는 역할과 동일 맥락이다.

 

객체지향설계적 관점으로 이를 다시 해석하자면, 호환성 없는 인터페이스 때문에 동작하지 못하는 클래스들을 동작할 수 있도록 중간에 변환해주는 패턴이라고 할 수 있다.

 

이러한 어댑터 패턴은 상속을 하냐, 합성을 하냐에 따라 두 가지 방법으로 나뉜다. 우리는 여기서 추천되는 방법인 객체 어댑터(Object Adapter)에 대해 알아볼 것이다.

 

상속을 사용하는 클래스 어댑터의 경우, C++ 같이 다중 상속을 지원해야 하기 때문이다.

 

 

 

 

 

Object Adapter Pattern

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/adapter

 

 

객체 어댑터(Object Adapter)의 큰 특징으로는 객체 합성의 원칙을 사용한다는 것이다. 즉, 합성을 통해서 Client는 Adapter를 통해 원하는 Service를 실행할 수 있다.

 

여기서 Service는 Adaptee라고도 불리는데, 이 객체가 Adapter의 멤버 변수로써 있어야 하기 때문에 공간 차지 비용이 조금 더 든다.

 

 

🔲 Service(Adaptee) : 호환되지 않는 외부 시스템, 써드파티 라이브러리

 

🔲 Client Interface : Adapter가 구현하는 인터페이스

 

🔲 Adapter : Client와 Service 사이를 이어주는 역할을 한다.

• Adaptee를 클래스 멤버로 설정한 후에, 위임을 통해서 동작하게 한다.

🔲 Client : Client Interface를 통해 Service를 수행할 수 있다.

 

 

 

 

 

Object Adapter Pattern을 C++로

 

#include <algorithm>
#include <iostream>
#include <sstream>
#include <vector>

class Json {};
class Xml {};
class Yaml {};

class Result {
  // Result 클래스의 정의
  // 결과 데이터 및 관련 메서드를 추가해야 함
};

class JsonAnalyzer {
  public:
  Result Analyze(Json json)  { /* JSON 분석 로직을 구현해야 함 */ }
};

class XmlAnalyzer {
  public:
  XmlAnalyzer() : json_analyzer_() {}

  Result Analyze(Xml xml) {
    return json_analyzer_.Analyze(ToJson(xml));
  }

  private:
  Json ToJson(Xml xml) { /* XML을 JSON으로 변환하는 로직을 구현해야 함 */ }
  JsonAnalyzer json_analyzer_;
};

class YamlAnalyzer {
  public:
  YamlAnalyzer() : json_analyzer_() {}

  Result Analyze(Yaml yaml) {
    return json_analyzer_.Analyze(ToJson(yaml));
  }

  private:
  Json ToJson(Yaml yaml) { /* YAML을 JSON으로 변환하는 로직을 구현해야 함 */ }
  JsonAnalyzer json_analyzer_;
};

Xml GetXmlFile() { /* XML 파일을 읽어오는 로직을 구현해야 함 */ }
Yaml GetYamlFile() { /* YAML 파일을 읽어오는 로직을 구현해야 함 */ }

int main() {
  Xml xml = GetXmlFile();
  Yaml yaml = GetYamlFile();

  XmlAnalyzer xml_analyzer;
  YamlAnalyzer yaml_analyzer;

  Result xml_analysis_result = xml_analyzer.Analyze(xml);
  Result yaml_analysis_result = yaml_analyzer.Analyze(yaml);
  
  // 결과를 처리하는 로직을 추가해야 함
}

 

구체적인 로직을 생략하고, 어떤 구조로 패턴이 동작하는 지 살펴보자.

 

🔲 Adaptee(Service) : JsonAnalyzer로, json 파일만을 받아 Result 객체로 변환해주는 서비스이다.

 

🔲 Adaptor : XmlAnalyzer, YamlAnalyzer로, xml과 yaml 파일을 받아 json으로 변환해주며 Adaptee(JsonAnlyzer)를 멤버 변수로 포함하고 있다.

 

🔲 Adaptee를 합성하는 부분은 private이며, 나머지 메소드 실행 부분은 public이다.

 

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/adapter

 

 

---

 

 

Bridge Patterns(브리지 패턴)

 

브리지 패턴은 객체의 확장성을 향상시키기 위한 패턴으로, 객체에 너무 많은 기능이 포함되어 유지 보수가 힘들 때 사용할 수 있다.

 

이를 위해 브리지는 상속 대신 객체 합성이라는 수단을 택한다. 상속을 사용한다면, 기하 급수적인 계층 구조가 형성될 수도 있기 때문이다.

 

Adapter에서도 Service에 대한 합성을 통해 호환성을 맞춰줬듯이, 브리지도 객체 합성을 통해 기능의 향상을 도모한다.

 

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/bridge

 

 

 

그림을 보면서도 알 수 있듯이, 모양이라는 클래스 안에 색이라는 객체를 포함 시킴으로써 확장에 더욱 유리해졌다.

 

---

 

브리지 패턴을 사용하는 경우

 

🔲 부모 추상 클래스(모양)에서 기본적인 규칙이 정의되어 있고, 구체적인 클래스(빨강, 파랑)가 추가 규칙을 설정하고 싶을 때

 

🔲 객체에 대한 참조가 있는 추상 클래스가 있고(모양), 구체적인 클래스에서 정의될 추상 메서드(색)가 존재할 때

 

---

 

 

추상화와 구현

 

브리지 패턴은 추상화와 구현으로 정의할 수 있다. 앞서 말했듯이, 브리지 패턴은 객체 합성을 통해서 구현한다고 했다. 즉, 객체 합성이 이루어지는 추상 클래스가 바로 추상화, 그리고 합성 당하는 객체를 구체적인 클래스로 생각할 수 있다.

 

이렇듯, 추상화와 구현 부분으로 나누는 이유는 "유지 보수" 때문이다. 만약 추상화나 구현 상관없이 전체 코드를 이해해야 하는 모놀로식 코드 베이스라면, 변경이 하나 발생할 때마다 너무나도 힘들 것이다.

 

하지만, 추상화 부분과 구현 부분을 나누고 브리지로 이어준다면, 굳이 전체 코드에 대한 이해가 없어도 변경하기 유리할 것이다.

 

 

 

 

Bridge Patterns(브리지 패턴)의 구조

 

 

출처 : https://refactoring.guru/ko/design-patterns/bridge

 

 

 

 

🔲 Abstraction(추상화) : Remote에 해당하는 부분으로, Client는 추상화를 통해 작업을 수행할 수 있다.

• private 멤버로 구현 부분인 Implementation 인터페이스를 포함한다.(객체 합성)

 

🔲 Implementiation(구현) : 구체적인 클래스에 대한 공통 인터페이스를 선언한다.

 

🔲 Concrete Impementations(구체적인 클래스) : 플랫폼 별 맞춤 코드가 제공된다.

 

🔲 Refined Abstraction(정제화된 추상화) : 추상화와 마찬가지로, 구현 인터페이스를 통해 작업한다

 

 

 

Bridge Patterns(브리지 패턴)을 C++로

 

 

 

#include <algorithm>
#include <iostream>
#include <sstream>
#include <vector>

class Implementation {
 public:
  virtual ~Implementation() {}
  virtual std::string OperationImplementation() const = 0;
};

class ConcreteImplementationA : public Implementation {
 public:
  std::string OperationImplementation() const override {
    return "ConcreteImplementationA: Here's the result on the platform A.\n";
  }
};

class ConcreteImplementationB : public Implementation {
 public:
  std::string OperationImplementation() const override {
    return "ConcreteImplementationB: Here's the result on the platform B.\n";
  }
};

class Abstraction {

 protected:
  Implementation* implementation_;

 public:
  Abstraction(Implementation* implementation) : implementation_(implementation) {
  }

  virtual ~Abstraction() {
  }

  virtual std::string Operation() const {
    return "Abstraction: Base operation with:\n" +
           this->implementation_->OperationImplementation();
  }
};

class ExtendedAbstraction : public Abstraction {
 public:
  ExtendedAbstraction(Implementation* implementation) : Abstraction(implementation) {
  }
  std::string Operation() const override {
    return "ExtendedAbstraction: Extended operation with:\n" +
           this->implementation_->OperationImplementation();
  }
};


void ClientCode(const Abstraction& abstraction) {
  // ...
  std::cout << abstraction.Operation();
  // ...
}

int main() {
  Implementation* implementation = new ConcreteImplementationA;
  Abstraction* abstraction = new Abstraction(implementation);
  ClientCode(*abstraction);
  std::cout << std::endl;
  delete implementation;
  delete abstraction;

  implementation = new ConcreteImplementationB;
  abstraction = new ExtendedAbstraction(implementation);
  ClientCode(*abstraction);

  delete implementation;
  delete abstraction;

  return 0;
}

 

🔲 Client는 Abstraction(추상화)을 통해서 실제 구현 객체들과 소통한다.

 

🔲 Abstraction은 private 멤버로 Implementation(구현 인터페이스)를 가진다.

 

🔲 ExtendedAbstraction은 Abstraction의 상속을 받은 클래스로 Abstraction과 동일하게 Implementation을 통해 소통한다.

 

 

 

 

실행 결과

Abstraction: Base operation with:
ConcreteImplementationA: Here's the result on the platform A.

ExtendedAbstraction: Extended operation with:
ConcreteImplementationB: Here's the result on the platform B.

 

 

 

 

 

Composite Pattern(복합체 패턴)

 

복합체 패턴(Composite Pattern)은 복합 객체(Composite)와 단일 객체(Leaf)를 동일한 컴포넌트로 취급하고, 단일 인터페이스를 사용하도록 하는 구조 패턴이다.

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/composite

 

예를 들어, 위와 같이 복잡한 주문이 들어 왔다고 하자. 총 가격을 계산하기 위해 일일이 제품 하나하나 마다 더하기를 해줄 수도 있다. 하지만 이러한 방식은 너무나도 비효율적이다.

 

따라서 복합체 패턴은 재귀적으로 업무를 위임하여 수행하는 방법을 제시한다. 이는 알고리즘의 DFS와 굉장히 유사하게 동작한다. DFS도 결국 재귀적으로 파고들어 일련의 업무를 수행하는 탐색 기법이기 때문이다.

 

복합체 패턴은 총가격을 계산하는 메서드를 공통 인터페이스를 통해서 제품들과 상자들에게 부여할 수 있다.

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/composite

 

 

 

 

 

Composite Pattern(복합체 패턴)의 구조

 

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/composite

 

 

 

🔲 Component : Leaf와 Composite를 묶는 공통 상위 인터페이스이다.

 

🔲 Composite : 복합 객체로, Leaf나 Composite를 보관하는 역할을 한다.

• 보관은 내부 리스트를 통해서 관리한다.
• add와 remove 메서드를 통해서 내부 리스트에 단일/복합 객체를 추가하고 삭제한다.
• excute()를 통해서 하위 복합 객체를 순환한다.

🔲 Leaf : 단일 객체이다. excute()를 수행하면, 내용물만 반환한다.

 

🔲 Client : Component를 통해서 모든 객체를 참조할 수 있다.

 

 

 

 

 

Composite Pattern(복합체 패턴)를 C++로

 

Component

class Company {
  public:
  void Hire(Employee* employee) {
    employees_.push_back(employee);
  }
  std::string GetInfo() {
    std::string res = "";
    for(Employee* employee : employees_) {
      res += employee -> GetInfo() + "\n";
    }
    return res;
  }
  private:
  std::vector<Employee*> employees_;
};

 

🔲 GetInfo()는 excute()로, 재귀적으로 이를 호출한다.

 

🔲 Hire()는 내부 리스트로, 단일/복합 객체를 추가하는 기능을 한다.

 

 

 

Leaf

class Employee {
  public:
  Employee(std::string name, int age, std::string dept) : name_(name),
  age_(age), dept_(dept) {}
  virtual std::string GetInfo() {
    return "Employee: " + name_ + "(" + std::to_string(age_) + ") @ " + dept_;
  }
  virtual ~Employee() {}

  protected:
  std::string name_;
  int age_;
  std::string dept_;
};

class Developer : public Employee {
  public:
  Developer(std::string name, int age, std::string dept) : Employee(name, age, dept) {}
  std::string GetInfo() {
    return "Developer: " + name_ + "(" + std::to_string(age_) + ") @ " + dept_;
  }
};

class Researcher : public Employee {
  public:
  Researcher(std::string name, int age, std::string dept) : Employee(name, age, dept) {}
  std::string GetInfo() {
    return "Researcher: " + name_ + "(" + std::to_string(age_) + ") @ " + dept_;
  }
};

class Leader : public Employee {
  public:
  Leader(std::string name, int age, std::string dept) : Employee(name, age, dept) {}
  std::string GetInfo() {
    return "Leader: " + name_ + "(" + std::to_string(age_) + ") @ " + dept_;
  }
};

 

 

 

🔲 이 예제의 경우, Composite의 역할을 하는 부분은 Company 밖에 없다. 즉, Company는 Composite이자, Component이다.

 

🔲 나머지 부분들은 전부, Leaf 부분으로 GetInfo()를 통해 그 내용물 만을 내놓는다. 이는 virtual을 통한 메서드 오버라이딩을 통해 수행된다.

 

 

 

 

Facade Pattern(퍼사드 패턴)

 

 

퍼사드(Facade) 패턴은 사용하고자하는 라이브러리나 외부 API를 내 코드와 결합하고자 할 때, 비즈니스 로직을 이해하기 쉽도록 클래스를 재정리하는 구조패턴이다.

 

또한 퍼사드 패턴은 다른 디자인 패턴과 달리 정형화되어 있지 않은 패턴이다. 그래서 클래스들간의 관계가 특별히 정해져 있거나 하지는 않다. 그저 퍼사드(Facade) 클래스를 통해서 기능이 집약화되기만 하면 된다. 복잡한 것을 간단하게 보여준다는 것이 퍼사드 패턴의 목적이기 때문이다.

 

 

퍼사드 패턴의 특징

 

1️⃣ 시스템이 너무 복잡할 때 사용한다.

 

2️⃣ 외부 라이브러리의 결합도가 너무 높을 때 사용한다.

 

3️⃣ 복잡한 코드를 감추고, Facade 클래스만을 통해 코드를 이해할 수 있다.

 

4️⃣ 코드의 양이 많아져, 유지보수 면에서 비용이 더 든다.

 

 

---

 

 

Facade Pattern(퍼사드 패턴)의 구조

 

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/facade

 

 

🔲 VideoConverter는 Facade 클래스로써, 복잡한 외부 라이브러리를 재정리하여 나타낸다.

 

🔲 Application은 외부 라이브러리에 대한 의존 없이 Facade를 통해서 작업을 수행한다.

 

 

 

 

Facade Pattern(퍼사드 패턴)을 C++로

 

#include <algorithm>
#include <iostream>
#include <sstream>
#include <vector>

class Subsystem1 {
 public:
  std::string Operation1() const { return "Subsystem1: Ready!\n"; }
  // ...
  std::string OperationN() const { return "Subsystem1: Go!\n"; }
};

class Subsystem2 {
 public:
  std::string Operation1() const { return "Subsystem2: Get ready!\n"; }
  // ...
  std::string OperationZ() const { return "Subsystem2: Fire!\n"; }
};

class Facade {
 protected:
  Subsystem1 *subsystem1_;
  Subsystem2 *subsystem2_;

 public:
  Facade(Subsystem1 *subsystem1 = nullptr, Subsystem2 *subsystem2 = nullptr) {
    this->subsystem1_ = subsystem1 ?: new Subsystem1;
    this->subsystem2_ = subsystem2 ?: new Subsystem2;
  }
  ~Facade() {
    delete subsystem1_;
    delete subsystem2_;
  }

  std::string Operation() {
    std::string result = "Facade initializes subsystems:\n";
    result += this->subsystem1_->Operation1();
    result += this->subsystem2_->Operation1();
    result += "Facade orders subsystems to perform the action:\n";
    result += this->subsystem1_->OperationN();
    result += this->subsystem2_->OperationZ();
    return result;
  }
};

void ClientCode(Facade *facade) {
  // ...
  std::cout << facade->Operation();
  // ...
}

int main() {
  Subsystem1 *subsystem1 = new Subsystem1;
  Subsystem2 *subsystem2 = new Subsystem2;
  Facade *facade = new Facade(subsystem1, subsystem2);
  ClientCode(facade);

  delete facade;

  return 0;
}

 

🔲 Facade 클래스는 두 SubSystem(외부 라이브러리라고 생각하자)에서 사용하는 메서드를 사용하여 동작을 기술한다.

 

🔲 Client는 subsystem을 Facade 객체에 등록시키고, 실행만 한다.(나머지 세부 로직은 Facade 내부에서 실행된다.

 

 

Facade Pattern(퍼사드 패턴)을 Java에서

 

데이터베이스에서 데이터를 조회하고 출력하는데 캐시 정보를 사용한다고 해보자. 그렇다면 아래와 같은 로직으로 데이터가 조회된다.

 

조회할 데이터 정보 변수 a;

if (데이터가 캐시에 있다면) {
    a = 캐시에서 조회 및 반환;
} else {
    a = DB에서 데이터 조회 및 반환;
    a를 캐시에 저장
}

a를 가공하여 출력

 

 

이 과정에서 사용해야 하는 클래스는 Cache 조회, DBMS 조회, Cache 입력, 조회 결과 가공, 가공 결과 출력이다.

이에 대한 클래스를 간단하게 나타내면 아래와 같은 것이다.

 

class Row  {
    private String name;
    private String birthday;
    private String email;

    public Row(String name, String birthday, String email) {
        this.name = name;
        this.birthday = birthday;
        this.email = email;
    }

    public String getName() {
        return name;
    }

    public String getBirthday() {
        return birthday;
    }

    public String getEmail() {
        return email;
    }
}

class DBMS {
    private HashMap<String, Row> db = new HashMap<>();

    public void put(String name, Row row) {
        db.put(name, row);
    }

    public Row query(String name) {
        try {
            Thread.sleep(500);
        } catch(InterruptedException e) {}

        return db.get(name.toLowerCase());
    }
}

class Cache {
    private HashMap<String, Row> cache = new HashMap<>();

    public void put(Row row) {
        cache.put(row.getName(), row);
    }

    public Row get(String name) {
        return cache.get(name);
    }
}

class Message {
    private Row row;

    public Message(Row row) {
        this.row = row;
    }

    public String makeName() {
        return "Name : \"" + row.getName() + "\"";
    }

    public String makeBirthday() {
        return "Birthday : " + row.getBirthday();
    }

    public String makeEmail() {
        return "Email : " + row.getEmail();
    }
}

 

위 클래스 코드를 main 함수에 하나하나 적용해나가며 로직을 구현한다면 이는 클린하지 못할 것이다. 유지 보수하기 힘들며 코드 로직을 해석하기도 힘들어지기 때문이다.

 

이에 따라 Facade 클래스를 도입하여 "데이터베이스에서 데이터를 조회하고 출력하는데 캐시 정보를 사용하는" 로직을 대신 수행하도록 한다면 유지보수와 코드 해석에 있어 매우 유리해 질 수 있다.

 

 

class Client {
    public static void main(String[] args) {

        Facade facade = new Facade();
        facade.insert();

		// 캐시 활용 DB 조회 기능을 하는 Facade의 run() 메서드
        String name = "홍길동";
        facade.run(name);
    }
}

 

 

 

 

Froxy Pattern(프록시 패턴)

 

프록시 패턴은 생긴 모양으로는 퍼사드 패턴과 큰 차이가 없다. 단, dependency 감소가 목적이었던 Facade와는 달리 Proxy는 성능 향상 및 인가가 주 목적이다.

 

 

즉, 프록시 패턴이란 원본 객체 대리로 로직을 처리하는 패턴인데, 원본 객체를 수정할 수 없는 상황일 때 사용한다. 이러한 프록시 패턴으로 누릴 수 있는 효과는 아래와 같다.

 

1️⃣ 보안 : 프록시에서 클라이언트의 권한을 확인하고 원복 객체로의 요청을 할 수 있는 지 확인하는 역할

 

2️⃣ 캐싱 : 프록시가 내부 캐시를 유지하여, 데이터에 대한 캐시를 이미 보유하고 있을 때 그대로 반환하는 역할

 

3️⃣ 데이터 유효성 검사 : 입력에 대한 유효성 검사 기능

 

4️⃣ 지연 초기화 : 만약 대상 객체가 생성할때 비용이 많이 든다면, 필요로 할때까지 기다렸다가 사용 시기에 생성하는 역할

 

5️⃣ 로깅 : 원본 객체에 대한 호출 시 로그를 남기는 역할

 

6️⃣ 원격 객체 : 프록시가 원격에 있는 객체를 가져와서 로컬처럼 보이도록 하는 역할

 

 

 

 

Froxy Pattern(프록시 패턴)의 구조

 

출처 :&nbsp;https://refactoring.guru/ko/design-patterns/proxy

 

🔲 사용자는 ServiceInterface를 통해서 대상 객체(Service)에 대한 작업을 수행할 수 있다.

 

🔲 Proxy는 대상 객체(Service)를 합성한다.

 

🔲 Service는 원본 대상 객체를 의미한다.

 

 

 

Froxy Pattern(프록시 패턴)을 C++로

 

보안과 캐싱의 기능을 하는 프록시 패턴을 간단하게 C++로 구현해보겠다.

 

 

 

준비할 클래스(캐싱 클래스, Person, Result 클래스)

class Result {
 public:
  Result() { /* 생성자 구현 */
  }
  // 다른 멤버 및 동작을 추가로 정의할 수 있습니다.
};

class Person {
 public:
  Person(std::string name) : name_(name) { }/* 생성자 구현 */
  std::string name() const {
    return name_;
  }
  
  private:
  std::string name_;
};

class Cache {
 public:
  Cache() { /* 생성자 구현 */
  }
  bool IsCached(std::string query) {
    // 캐시 확인 로직 구현
    return false;
  }

  Result GetCachedData(std::string query) {
    // 캐시된 데이터 반환 로직 구현
    return Result();
  }

  void Update(std::string query, std::experimental::optional<Result> result) {
    std::cout << "update cache for person" << std::endl;
    // 캐시 업데이트 로직 구현
  }
};

 

 

 

 

Service Interface, Service, Proxy

class QueryInterface {
public:
    virtual std::experimental::optional<Result> Query(Person accessor, std::string query) = 0;
};

class NetworkAdapter : public QueryInterface {
public:
    std::experimental::optional<Result> Query(Person accessor, std::string query) override {
        // 네트워크에서 데이터를 가져오는 로직 구현
        std::cout << "data fetch in NetworkAdapter." << std::endl;
        return Result();
    }
};

class NetworkProxy : public QueryInterface {
public:
    NetworkProxy(Person manager) : network_manager_(manager) {}
    std::experimental::optional<Result> Query(Person accessor, std::string query) override {
        // 들어온 값에 대한 인가 과정
        if (network_manager_.name() == accessor.name()) {
            // 캐쉬가 있다면, 그대로 줌
            if (cache_.IsCached(query)) {
                return cache_.GetCachedData(query);
            // 캐쉬가 없다면, network_adapter로 부터 가져옴
            } else {
                std::experimental::optional<Result> result = network_adapter_.Query(accessor, query);  // Query 함수의 시그니처 변경
                cache_.Update(query, result);
                return result;
            }
        }
        // 아예 없으면 null 값 리턴
        return std::experimental::nullopt;
    }

private:
    const Person network_manager_;
    Cache cache_;
    NetworkAdapter network_adapter_;
};

 

 

🔲 QueryInterface : Service Interface로 하위 자식으로 Proxy와 Service를 둔다.

 

🔲 NetworkAdapter : Service로 실제 데이터를 주는 클래스이다.

 

🔲 NetworkProxy : 캐싱 기능과 보안 기능을 수행한다. NetworkAdapter를 합성한다.

 

 

main 함수

int main() {
  Person manager("person1");               // Person 객체 생성
  NetworkProxy proxy(manager);  // NetworkProxy 객체 생성
  std::experimental::optional<Result> result1 =
      proxy.Query(manager, "find name from internet");
  std::experimental::optional<Result> result2 =
      proxy.Query(manager, "find name from internet");
}

 

 

실행 결과

data fetch in NetworkAdapter.
update cache for person
data fetch in NetworkAdapter.
update cache for person

 

 

자바에서도 Dynamic Proxy, Spring Framework에서는 Spring AOP 등 Proxy는 정말 많은 곳에서 쓰이고 있다. 이와 관련된 부분은 후에 포스팅 예정이다.

 

 

 

 

 

References

 

디자인 패턴들

[Java][디자인 패턴] 8. 브리지 패턴 (Bridge Pattern)

 

💠 복합체(Composite) 패턴 - 완벽 마스터하기

코딩으로 학습하는 GoF의 디자인 패턴 - 인프런 | 강의

 

💠 퍼사드(Facade) 패턴 - 완벽 마스터하기

💠 어댑터(Adaptor) 패턴 - 완벽 마스터하기

💠 프록시(Proxy) 패턴 - 완벽 마스터하기

 

💠 추상 팩토리(Abstract Factory) 패턴 - 완벽 마스터하기