[객체지향설계] GoF(Gang of Four) 디자인 패턴(싱글톤, 빌더)

 

 

디자인 패턴은 무엇인가?

 

디자인 패턴은 소프트웨어 설계에 있어 공통된 문제들에 대한 표준적인 해법과 작명법을 제안한 책이다. 이 분야에 있어, 사인방이라고 불리는 Erich Gamma, Richard Helm, Ralph Jonhson, John Vlissides가 작성했기에 Gang of Four(GoF)라고 불리곤 한다.

 

즉, 디자인 패턴은 프로그램을 개발하는 과정에서 우리 앞에 놓여진 비슷한 문제들을 해결하기 위해 일련의 "패턴"을 만들어 쉽게 해결할 수 있도록 한 것이다. 이를 잘 숙지하고 활용한다면 많은 시간과 노력을 줄일 수 있을 것이다.

 

그러한 패턴은 크게 용도에 따라 생성 패턴(Creational Patterns), 구조 패턴(Structural Patterns), 행동 패턴(Behavioral Pattern)으로 나뉜다.

 

💡 생성 패턴은 객체 인스턴스를 생성하는 패턴으로 클라이언트가 생성해야 하는 객체 인스턴스 사이의 연결을 끊어주는 패턴이다.


💡구조 패턴은 클래스와 객체를 더 큰 구조로 만들 수 있게 구성을 사용하는 패턴이다.


💡행동 패턴은 클래스와 객체들이 상호작용하는 방법과 역할을 분담하는 방법을 다루는 패턴이다.

 

 

물론 패턴이 어느 분류에 속하는 지 아는 것도 중요하지만, 패턴이 정확히 어떤 역할을 하는 지 이해하는 것이 중요하다고 본다.

 

 

 

 

Creational Design Patterns

 

 

생성 패턴은 객체의 생성과 관련된 패턴을 다루며 캡슐화나 유연성있는 코드를 목표로 둔다. 이러한 패턴에는 대표적으로 아래와 같다.

 

• Factory method
• Abstract factory
• Builder
• Prototype
• Singleton
• ...

 

 

 

 

Singleton pattern(싱글톤 패턴)

 

디자인 패턴 중에서도 개념적으로는 가장 간단한 싱글톤 패턴이다.

 

물론, 간단한 만큼 어느 경우에 어떤 코드로 작성해야 하는 지 모르는 경우가 많아 제대로 알지 못하고 사용하는 경우가 많다고 한다. 그렇기에 면접이나 앞으로의 객체 지향의 기본을 이해하기 위해서 제대로 파악해보자.

 

 

싱글톤 패턴은 단 하나의 유일한 객체를 만들기 위한 코드 패턴이다.

 

그 목적은 메모리 절약을 위한 것이고, 동일한 인스턴스를 사용하기 위해 새롭게 인스턴스를 생성하지 않는다. 이는 마치 전역 변수와 유사하게 작동한다. 어디서든지 액세스될 수 있기 때문이다.

 

따라서 싱글톤 패턴이 적용된 객체는 대체적으로 리소스를 많이 차지하는 역할일 때 사용한다. 가령 데이터베이스 모듈을 그 예로 들 수 있다. 이 과정에서 발생하는 I/O바운드는 무거운 작업에 속하고, 굳이 여러 번 만들 필요도 없기 때문이다.

 

이 외에도 디스크 연결, 네트워크 통신, DBCP 커넥션 풀, 스레드 풀, 캐시, 로그 기록 객체 등 리소스를 많이 차지하는 객체에서 사용한다.

 

 

 

 

 

 

싱글톤 패턴은 어떻게 만드는데?

 

만드는 방법은 간단하지만 생각보다 여러 방법이 있다. 그 코드 기법은 크게 7가지로 나뉘며 이는 상황에 맞게 사용해야한다.

 

• Eager Initalization
• Static block initialization
• Lazy Iinitialization
• Thread safe initialization
• Double-Checked Locking
• Bill Pugh Solution
• Enum 이용

 

뭐 간단하다면서 엄청 많네? 라고 생각할 수 있다. 많긴 해도 여기서 소개할 것은 Lazy Initialization뿐이며, 다른 부분들은 구글이나 관련 문서를 찾아보면 굉장히 많으므로 찾아보길 바란다. 우리는 패턴 자체를 이해하는 것에 목적을 두기 때문이다. 물론 자바 개발자라면, 싱글톤 구현 방법 7개쯤(?)은 가볍게 학습하는 걸 권장한다.

 

사실 위 7개는 위에서부터 각 단점을 보완하며 나온 것이다. 그래서 바로 활용을 해야 한다면 Bill Pugh Solution과 Enum에 대한 이용 예제를 학습하는 것이 좋다.(언제까지나 Lazy Initialzation이 이해하기 좋으며, 자료도 많기 때문이다.)

 

 

그래서 소개할 Lazy Initialization의 특징은 아래와 같다.

 

🔲 객체 생성에 대한 관리를 내부적으로 처리한다.

 

🔲 만들어진 인스턴스가 null인지 아닌지 여부에 따라 초기화/반환한다.

 

🔲 단, 쓰레드 세이프(Thread Safe)하지 않는다.

 

⚠ 왜 쓰레드 세이프 하지 않는가?

자바는 멀티 쓰레드 언어인데, 이 환경에서는 쓰레드 세이프하지 않는다.
멀티쓰레드 언에서 여러 쓰레드에서 동시에 접근하면 동시에 null 체크를 하게 된다. 이로인해 동시에 실행되는 쓰레드들에서 null 체크에 대한 검사가 두 번이상 통과되는 치명적인 문제가 발생한다.
그렇게 되면 인스턴스가 두 개 이상 생기고, 이는 싱글톤 패턴에 부합하지 않기 때문이다.

 

 

이에 대한 C++ 코드 예시를 살펴보자.

 

class Singleton
{
public:
    Singleton(Singleton &other) = delete;
    void operator=(const Singleton &) = delete;

    static Singleton *GetInstance(const std::string &value)
    {
        if (instance_ == nullptr)
            instance_ = new Singleton(value);
        return instance_;
    }
    std::string value() const { return value_; }

private:
    Singleton(const std::string value) : value_(value) {}
    static Singleton *instance_;
    std::string value_;
};

Singleton *Singleton::instance_ = nullptr;

int main()
{
    Singleton *instance1 = Singleton::GetInstance("First");
    Singleton *instance2 = Singleton::GetInstance("Second");

    std::cout << instance1->value() << std::endl; // fisrt
    std::cout << instance2->value() << std::endl; // first

    return 1;
}

 

🔲 `delete`를 통해서 copy가 될 가능성을 막는다. 이는 인스턴스가 유일해야하기 때문이다.

 

🔲 instance가 nullptr인지 확인해주고, nullptr이면 새롭게 생성해주고 리턴해준다.

 

🔲 실제 생성자는 class 내부에 private로 선언해준다. 따라서 외부에서 접근할 수 없다.

 

🔲 초기에 인스턴스는 nullptr로 선언해주어야 한다. 이는 클래스 밖에서 해주어야 한다.

 

---

 

따라서 인스턴스를 두번 생성해주려는 해당 코드는 첫번째 인스턴스밖에 사용할 수 밖에 없다.

아래 그림을 통해서 싱글톤에 대한 구조를 쉽게 이해해보자.

 

 

출처 : https://refactoring.guru/design-patterns/singleton

 

 

 

밑줄은 static, : 뒤에는 타입 명시

 

 

 

싱글톤 패턴은 무조건 좋은 것인가?

 

당연히 아니다. 물론 DB 커넥션 풀같이 공통된 객체를 여러개 생성하거나, 리소스를 많이 차지하는 객체의 경우에는 이점도 많다. 하지만, 싱글톤은 그 특징 자체만으로 얻을 수 있는 불이익도 많다.

 

 

1. 모듈간의 의존성 증가

 

싱글톤은 앞서 배웠듯이 미리 생성한 객체를 사용한다. 이는 모듈들간의 강한 의존성을 불러일으킨다. 여러 모듈들에서 싱글톤을 적용한 동일한 객체를 사용한다고 해보자. 이때 이 싱글톤 객체가 바뀌면 나머지 모듈들도 전부 수정이 필요한 귀찮은 상황이 발생할 것이다.

 

즉, 싱글톤 객체를 사용하게 되면, 불필요하게 수정을 해야하는 경우가 많이 생겨 좋지 못하다.

 

2. SOLID 원칙 위배 가능성

 

인터페이스와 같은 추상화에 의존하는 것이 아닌, 구체 클래스에 의존하는 것은 의존 역전 원칙(DIP)에 위반된다. 또한 싱글톤 자체가 너무 많은 책임을 지는 경우가 많아 단일 책임 원칙(SRP)에도 부합하지 않을 수 있다. 그리고 앞서 본 모듈간의 의존성 증가는 곧, 클래스들 간의 결합도가 높다는 것을 의미한다. 이는 개방-폐쇄 원칙(OCP)에도 위배된다.

 

 

뿐만 아니라 테스트 코드를 짜기 힘들다는 단점도 존재한다. 이렇듯, 싱글톤 패턴은 그 장점만큼이나 단점도 많은 패턴이다. 

 

 

 

❕알아서 관리해주는 Spring 컨테이너

우리가 직접 만드는 것보단, 미리 만들어져 있는 프레임워크의 도움을 받는 것이 훨씬 좋다. 앞서 말했던 싱글톤의 단점을 전부 보완해주기 때문이다.

이는 Spring 컨테이너가 각각의 객체를 전부 싱글톤으로 존재할 수 있도록 관리해 주며, 클래스 제어를 컨테이너가 맡는 IoC 방식을 사용하기 때문이다.

 

 

 

Builder Pattern(빌더 패턴)

 

생성 패턴의 일종인 빌더 패턴은 기존의 생성자에서 특성 값이 너무 많을 때 사용할 수 있는 기법이다.

그래서 동일한 프로세스를 거쳐 다양한 구성의 인스턴스를 만들 수 있다.

 

 

출처 : https://refactoring.guru/design-patterns/builder

 

 

사진에서도 보는 바와 같이 House를 만드는데에 일반적인 생성자(constructor)를 사용한다고 생각해보자. new 연산자를 통해서 인스턴스를 생성해주고, 없는 값에 대해서는 null로 넣어주었다. 이는 직관적이지 않다. true라고 적혀있는 부분이 어느 프로퍼티를 가리키는지 알아보기도 힘들다.

 

이를 해결하기 위한 Solution으로 빌더 패턴을 사용할 수 있다.

빌더 패턴은 넘겨주어야 하는 인자의 순서를 지킬필요가 없으며 Optional한 데이터를 전부 적어줄 필요도 없다.

 

 

정리하자면, 빌더 패턴은 Optional한 데이터에 대한 처리를 일일이 해주었던 기존의 생성자의 단점을 보완하기 위해 사용한다.

 

 

빌더 패턴의 구조

 

 

앞서 설명한 빌더 패턴을 엄밀히 구분을 짓자면 Simple 빌더 패턴이다. Simple 빌더 패턴은 코드의 가독성, 일관성, 그리고 불변성에 초점을 두기 때문이다.

 

Simple 빌더 패턴은 Effective Java(이펙티브 자바)에서 소개하는 빌더 패턴이다. 우리가 지금부터 알아야 하는 것은 GOF 빌더 패턴이다.

 

 

 

GOF에서 정의하고 있는 빌더 패턴은 객체의 생성 알고리즘과 조립 방법을 분리하여 빌드 공정을 생성하는 것을 목표로 한다. 그래서 이 조립 방법을 정의한 클래스를 Director라고 부른다.

 

간단하게 객체만 생성하면 되지, 왜 굳이 객체를 생성하는 알고리즘과 조립 방법을 분리하는 걸까? 이는 여러가지 빌드 형식을 유연하게 처리할 수 있기 때문이다.(유연한 빌드 처리)

 

 

Director 빌더 패턴 구조

출처 : https://refactoring.guru/design-patterns/builder

 

 

오른쪽과 왼쪽 그림은 동일한 구조이며, 예시만 다른 Director 패턴 구조이다.

 

🔲 Builder : 빌더 추상 클래스

 

🔲 ConcreteBuilder : 빌더의 구현체

 

🔲 Director : 빌더에서 제공하는 메서드들을 사용해서 순서대로 Product(혹은 Car)를 생성하는 과정을 정의

 

🔲 Product/Car : Director가 Builder로 만들어낸 결과물

 

---

 

조금 더 쉽게 이해해 보자면, Director는 빌더 추상 클래스인 Builder의 메서드들을 통해서 Product를 만든다라고 생각하자. Director가 받는 인자의 값은 구체화된 Builder가 되고, 이는 ConcreateBuilder일 것이다. 그리고 Director는 Builder에서 제공하는 메서드를 통해서 실제 Product를 만들 수 있는 것이다.

 

다시말해, 구체화된 Builder는 부품을 만들고, Director는 추상화된 Builder 클래스의 메서드를 통해서 알맞은 제품을 만들 수 있다.

 

 

 

 

GOF 빌더 패턴을 C++으로(Simple 빌더 패턴)

 

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

class House {
 private:
  House(std::string name, bool has_roof, bool has_garage,
        bool has_swimming_pool, bool has_garden, int num_of_doors)
      : name_(name),
        has_roof_(has_roof),
        has_garage_(has_garage),
        has_swimming_pool_(has_swimming_pool),
        has_garden_(has_garage),
        num_of_doors_(num_of_doors) {}
  const std::string name_;
  const bool has_roof_;
  const bool has_garage_;
  const bool has_swimming_pool_;
  const bool has_garden_;
  const int num_of_doors_;

  friend HouseBuilder;
};

class HouseBuilder {
 public:
  void reset() {
    name_ = "";
    has_roof_ = false;
    has_garden_ = false;
    has_swimming_pool_ = false;
    has_garden_ = false;
    num_of_doors_ = 0;
  }

  HouseBuilder &SetName(std::string name) {
    name_ = name;
    return *this;
  }
  HouseBuilder &AddRoof() {
    has_roof_ = true;
    return *this;
  }
  HouseBuilder &AddGarage() {
    has_garage_ = true;
    return *this;
  }
  HouseBuilder &AddSwimmingPool() {
    has_swimming_pool_ = true;
    return *this;
  }
  HouseBuilder &AddGarden() {
    has_garden_ = true;
    return *this;
  }
  HouseBuilder &SetNumOfDoors(int n) {
    num_of_doors_ = n;
    return *this;
  }
  House *Build() {
    return new House(name_, has_roof_, has_garage_, has_swimming_pool_,
                     has_garden_, num_of_doors_);
  }

 private:
  std::string name_;
  bool has_roof_;
  bool has_garage_;
  bool has_swimming_pool_;
  bool has_garden_;
  int num_of_doors_;
};

int main() {
  HouseBuilder builder;
  House *my_house = builder.SetName("my house")
                        .AddRoof()
                        .AddGarage()
                        .AddGarden()
                        .SetNumOfDoors(4)
                        .Build();

  return 1;
}

 

 

 

비교적 간단한 Simple 빌더 패턴으로 코드를 구현해보자.

 

🔲 House 클래스는 HouseBuilder를 friend로 두었으며, 생성자를 private로 두었다. 즉, HouseBuilder만이 House 객체를 생성할 수 있다.

 

🔲 friend로 두는 이유는 순환 참조를 막기 위함이다. 즉, 이미 생성한 객체에 대한 변경이 이루어지는 것을 막을 수 있다.

 

🔲 .Build()를 통해 실제 객체를 생성할 수 있다.

 

🔲 HouseBuilder&는 레퍼런스 값을 가지는 것으로, 체이닝 기법을 통해서 연쇄적으로 프로퍼티에 대한 설정이 가능하다.

 

 

⚠️ 아래 코드는 순환 참조가 일어나, 이미 생성된 객체의 프로퍼티가 변경되는 자바 코드 예시이다.

class Product {
public:
    void setPropertyA(int value) {
        propertyA = value;
    }

    void setPropertyB(int value) {
        propertyB = value;
    }

    void displayProperties() {
        std::cout << "Property A: " << propertyA << ", Property B: " << propertyB << std::endl;
    }

private:
    int propertyA;
    int propertyB;
};

class ProductBuilder {
public:
    void buildProduct() {
        product = new Product();
    }

    void setPropertyA(int value) {
        // 여기서 Product 객체의 propertyA를 변경하려는 시도
        product->setPropertyA(value);
    }

    void setPropertyB(int value) {
        // 여기서 Product 객체의 propertyB를 변경하려는 시도
        product->setPropertyB(value);
    }

    Product* getResult() {
        return product;
    }

private:
    Product* product;
};

int main() {
    ProductBuilder builder;
    builder.buildProduct(); // Product 객체를 생성

    // 여기서 ProductBuilder가 이미 생성한 Product 객체를 참조하고 변경하려는 시도
    builder.setPropertyA(42);
    builder.setPropertyB(64);

    Product* finalProduct = builder.getResult();
    finalProduct->displayProperties();

    return 0;
}

 

 

 

 

Reference

 

Builder

💠 빌더(Builder) 패턴 - 완벽 마스터하기

 

💠 싱글톤(Singleton) 패턴 - 꼼꼼하게 알아보자