🎨 03. 데코레이터 패턴

☕ 초대형 커피 전문점, 스타버즈

단기간에 폭발적으로 성장한 스타버즈 카페는 다양한 음료를 모두 포괄하는 주문 시스템을 갖추지 못했다. 사업이 안정화된 지금에서야 주문 시스템을 개선하려고 노력하는 중인데, 사업을 시작할 무렵 만들어진 주문 시스템 클래스는 다음과 같이 구성되었다.

// 음료를 나타내는 추상 클래스
abstract class Beverage {
  protected description: string = "알 수 없는 음료";

  getDescription(): string {
    return this.description;
  }

  // cost()는 서브클래스에서 반드시 구현해야 하는 추상 메소드
  abstract cost(): number;
}

// 다크 로스트 커피 서브클래스
class DarkRoast extends Beverage {
  constructor() {
    super();
    this.description = "가장 훌륭한 다크 로스트 커피";
  }

  cost(): number {
    return 2.99;
  }
}

// 하우스 블렌드 커피 서브클래스
class HouseBlend extends Beverage {
  constructor() {
    super();
    this.description = "부드러운 하우스 블렌드 커피";
  }

  cost(): number {
    return 2.49;
  }
}

// 사용 예제
const myCoffee: Beverage = new DarkRoast();
console.log(myCoffee.getDescription()); // 가장 훌륭한 다크 로스트 커피
console.log(`가격: $${myCoffee.cost()}`); // 가격: $2.99

• Beverage는 음료를 나타내는 추상 클래스이며 매장에서 판매되는 모든 음료는 해당 클래스의 서브클래스가 됨.
• description이라는 인스턴스 변수는 각 서브클래스에서 설정되며, 변수에 저장된 내용은 getDescription() 메소드를 호출해서 확인할 수 있음.
• cost() 메소드는 추상 메소드로, 모든 서브클래스에서 음료의 가격을 리턴하는 cost() 메소드를 구현하여 새로 정의해야 함.

고객은 커피를 주문할 때 우유나 두유, 모카를 추가하고 그 위에 휘핑크림을 얹기도 한다. 각각을 추가할 때마다 커피 가격이 올라가야 하기에 주문 시스템을 구현할 때 이런 점을 모두 고려해야 한다.

class DarkRoast {
  description: string = "가장 훌륭한 다크 로스트 커피";

  cost(): number {
    return 2.99;
  }
}

class HouseBlend {
  description: string = "부드러운 하우스 블렌드 커피";

  cost(): number {
    return 2.49;
  }
}

// 💥: 조합별로 새로운 클래스를 추가해야 함
class DarkRoastWithMilk {
  description: string = "가장 훌륭한 다크 로스트 커피 + 우유";

  cost(): number {
    return 2.99 + 0.50;
  }
}

class DarkRoastWithMilkAndWhip {
  description: string = "가장 훌륭한 다크 로스트 커피 + 우유 + 휘핑크림";

  cost(): number {
    return 2.99 + 0.50 + 0.60;
  }
}

class HouseBlendWithMocha {
  description: string = "부드러운 하우스 블렌드 커피 + 초콜릿";

  cost(): number {
    return 2.49 + 0.70;
  }
}
.
.
.

❓ 지금까지 배운 디자인 원칙 중 무엇을 지키지 않고 있을까?

💡 디자인 원칙 1: 변하는 부분을 캡슐화하라

• 우유 가격, 추가 옵션(휘핑크림, 초콜릿 등)은 변하는 요소인데, 이걸 cost() 메서드 안에서 직접 하드코딩하고 있음.

💡 디자인 원칙 2: 상속보다는 구성(Composition)을 활용하라

• 현재 구조는 DarkRoastWithMilkAndCaramel 같은 클래스를 계속 상속해서 만들고 있음.

💡 디자인 원칙 3: 클래스는 확장에는 열려 있어야 하지만, 변경에는 닫혀 있어야 한다. (OCP - 개방/폐쇄 원칙)

• 우유 가격이 바뀌거나, 새로운 재료(캐러멜 등)가 추가될 때,기존 코드를 수정해야 하는 구조이므로 OCP 원칙을 어기고 있음.

인스턴수 변수와 슈퍼클래스 상속을 써서 첨가물을 관리하면 되지 않을까?

📌 Beverage 클래스 (음료 기본 클래스)

• description: 음료 설명을 저장하는 변수 (예: “가장 훌륭한 다크 로스트 커피”)
• hasMilk, hasSoy, hasMocha, hasWhip: 첨가물이 추가되었는지 여부를 저장하는 불리언 값
• setMilk(), setSoy(), setMocha(), setWhip(): 첨가물을 추가하는 메소드
• cost(): 서브클래스에서 이 메서드를 호출하여 추가 비용을 더할 수 있음

class Beverage {
  description: string = "알 수 없는 음료";
  hasMilk: boolean = false;
  hasSoy: boolean = false;
  hasMocha: boolean = false;
  hasWhip: boolean = false;

  getDescription(): string {
    return this.description;
  }

  setMilk(): void {
    this.hasMilk = true;
  }
  setSoy(): void {
    this.hasSoy = true;
  }
  setMocha(): void {
    this.hasMocha = true;
  }
  setWhip(): void {
    this.hasWhip = true;
  }

  cost(): number {
    let totalCost = 0;

    // 음료 기본 가격 (서브클래스에서 설정)
    totalCost += this.getBaseCost();

    // 첨가물 가격 추가
    if (this.hasMilk) totalCost += 0.50;
    if (this.hasSoy) totalCost += 0.60;
    if (this.hasMocha) totalCost += 0.70;
    if (this.hasWhip) totalCost += 0.60;

    return totalCost;
  }
}

📌 DarkRoast & HouseBlend 클래스 (음료 종류별 클래스)

• DarkRoast와 HouseBlend 클래스는 Beverage 클래스를 상속받음.
• Beverage 클래스에서 cost()를 기본 구현 (첨가물 가격만 계산)
• 서브클래스(DarkRoast, HouseBlend)에서는 기본 가격만 설정하고, super.cost() 호출

class DarkRoast extends Beverage {
  constructor() {
    super();
    this.description = "가장 훌륭한 다크 로스트 커피";
  }

  cost(): number {
    return 2.99 + super.cost(); // 기본 가격 + 첨가물 가격
  }
}

class HouseBlend extends Beverage {
  constructor() {
    super();
    this.description = "부드러운 하우스 블렌드 커피";
  }

  cost(): number {
    return 2.49 + super.cost(); // 기본 가격 + 첨가물 가격
  }
}

이 프로젝트에서 변경되었을 때 디자인에 영향을 미칠 만한 요소를 적어보자.

• 첨가물 가격이 바뀔 때마다 기존 코드를 수정해야 한다.
  • 첨가물 가격이 바뀌면 Beverage 클래스의 cost() 메서드에서 직접 수정해야 함.
  • 확장성이 떨어짐. 새로 추가된 가격 변화가 있을 때마다 모든 서브클래스를 수정해야 할 수 있음.
• 첨가물의 종류가 많아지면 새로운 메소드를 추가해야 하고, 슈퍼클래스의 cost() 메소드도 고쳐야 한다.
  • 새로운 첨가물이 추가되면 setMilk(), setSoy() 같은 메서드를 하나씩 추가해야 하므로 유지보수가 어려워짐.
  • 첨가물 종류가 많아질수록 슈퍼클래스 cost() 메서드가 복잡해짐.
• 새로운 음료가 출시될 수도 있다. 특정 첨가물이 들어가면 안 되는 음료도 있을 것이다.
  • 음료 별로 첨가물이 제한될 수 있음. 예를 들어, 어떤 음료는 우유나 두유를 넣을 수 없을 수 있음.
  • Beverage 클래스의 구현을 수정해야 하는데, 제약이 많아지면 유지보수가 힘들어짐.
• 고객이 더블 모카를 주문하면 어떻게 해야 될까?
  • 더블 모카는 모카를 두 번 넣는 옵션이므로, 이를 구현하려면 cost() 메서드가 확장될 필요 있음.
  • 만약 모카 추가가 두 번 이상 가능하다면, setMocha() 메서드를 추가하거나 cost() 메서드를 더 복잡하게 작성해야 함.
• 새로운 첨가물 옵션을 도입해야 할 때마다, 모든 음료 클래스를 수정해야 한다.
  • 예를 들어, 캐러멜이나 시럽 같은 새로운 첨가물이 추가될 때마다, 각 음료 클래스에서 이를 다루는 로직을 추가해야 한다.
  • 이로 인해 객체지향 원칙인 개방-폐쇄 원칙(OCP)을 위반하게 되며, 수정의 범위가 커지므로 관리가 어려워진다.
• 기본 음료 가격을 바꾸거나 할인 이벤트를 추가할 때, 모든 음료 클래스를 수정해야 한다.
  • 음료의 기본 가격에 변동이 생기면 각 음료 클래스에서 가격을 수정해야 하는데, 중복 코드가 많이 생기기 때문에 효율적이지 않음.
  • 할인이나 프로모션 가격을 추가하려면, 각각의 음료 클래스에서 이를 적용할 방법을 찾아야 하므로 유지보수가 번거롭다.
• 음료의 수가 증가하면 Beverage 클래스를 확장하는 서브클래스들이 많아지므로 코드가 길어지고 복잡해진다.
  • 음료 종류가 많아지면 DarkRoast, HouseBlend 같은 서브클래스가 많아지고, 이를 관리하기 어려워짐.
  • 상속 구조가 깊어지거나 많은 서브클래스를 처리하는데 문제가 발생할 수 있음.
• 각 음료의 가격 계산 로직이 중복된다.
  • 각 서브클래스에서 cost() 메서드를 구현할 때마다 비슷한 방식으로 가격을 계산하게 되므로, 중복 코드가 발생.
  • 이로 인해 새로운 음료나 첨가물이 추가될 때마다 가격 계산 로직을 반복해야 한다는 단점이 생김.

---

☕ OCP 살펴보기

OCP(OPEN-CLOSED PRINCIPLE)는 정말 중요한 디자인 원칙 중 하나이다.

클래스는 확장에는 열려 있어야 하지만 변경에는 닫혀 있어야 한다.

우리의 목표는 기존 코드를 건드리지 않고 확장으로 새로운 행동을 추가하는 것이다. 이 목표를 달성했을 때 무엇을 얻을 수 있을까? 새로운 기능을 추가할 때 급변하는 주변 환경에 잘 적응하는 유연하고 튼튼한 디자인을 만들 수 있다!

---

☕ 데코레이터 패턴 살펴보기

다른 방법으로, 일단 특정 음료에서 시작해서 첨가물로 그 음료를 장식(decorate)한다고 생각해 보자. 예를 들어 어떤 고객이 모카와 휘핑크림을 추가한 다크 로스트 커피를 주문한다면 다음과 같이 장식할 수 있다.

1. DarkRoast 객체를 가져온다.
2. Mocha 객체로 장식한다.
3. Whip 객체로 장식한다.
4. cost() 메소드를 호출한다. 이때 첨가물의 가격을 계산하는 일은 해당 객체에게 위임한다.

여기서 객체를 어떻게 장식할 수 있을까? 그리고 이 과정에서 어떤 식으로 위임할 수 있을까?

---

☕ 주문 시스템에 데코레이터 패턴 적용하기

• DarkRoast는 Beverage로부터 상속받으므로 음료의 가격을 계산하는 메소드를 가지고 있다.
• 고객이 모카를 주문했으므로 Mocha 객체를 만들고 그 객체로 DarkRoast를 감싼다.
  • Mocha 객체는 데코레이터이다. 객체의 형식은 객체가 장식하고 있는 객체를 반영하는데(여기서는 Beverage), 여기서 반영한다는 것은 “같은 형식을 갖는다.” 라는 뜻으로 이해하면 된다.
  • 따라서 Mocha에도 cost() 메소드가 있고, Mocha가 감싸고 있는 것도 Beverage 객체로 간주할 수 있다. Mocha도 Beverage의 서브클래스 형식이기 때문이다.

• 고객이 휘핑크림도 추가했으니까 Whip 데코레이터를 만들어 Mocha를 감싼다.
  • Whip도 데코레이터라서 DarkRoast의 형식을 반영하며, cost() 메소드를 가진다.
  • Mocha와 Whip에 싸여 있는 DarkRoast는 여전히 Beverage 객체이기에 cost() 메소드 호출을 비롯한 DarkRoast에 관한 일이라면 무엇이든 할 수 있다.
• 가격을 구할 때는 가장 바깥쪽에 있는 데코레이터인 Whip의 cost()를 호출하면 된다. 그러면 Whip은 그 객체가 장식하고 있는 객체에게 가격 계산을 위임한다. 가격이 구해지고 나면, 계산된 가격에 휘핑크림의 가격을 더한 다음 그 결과값을 리턴한다.

❗정리

• 데코레이터의 슈퍼클래스는 자신이 장식하고 있는 객체의 슈퍼클래스와 같다.
• 한 객체를 여러 개의 데코레이터로 감쌀 수 있다.
• 데코레이터는 자신이 감싸고 있는 객체와 같은 슈퍼클래스를 가지고 있기에 원래 객체(싸여 있는 객체)가 들어갈 자리에 데코레이터 객체를 넣어도 상관없다.
• 데코레이터는 자신이 장식하고 있는 객체에게 어떤 행동을 위임하는 일 말고도 추가 작업을 수행할 수 있다.
• 객체는 언제든지 감쌀 수 있으므로 실행 중에 필요한 데코레이터를 마음대로 적용할 수 있다.

---

☕ 데코레이터 패턴의 정의

데코레이터 패턴(Decorator Pattern)으로 객체에 추가 요소를 동적으로 더할 수 있다. 데코레이터를 사용하면 서브클래스를 만들 때보다 훨씬 유연하게 기능을 확장할 수 있다.

• 각 구성 요소는 직접 쓰일 수도 있고 데코레이터에 감싸여 쓰일 수도 있다.
• 각 데코레이터 안에는 Component 객체가 들어있다. 즉, 데코레이터에는 구성 요소의 레퍼런스를 포함한 인스턴스 변수가 있다.
• Decorator는 자신이 장식할 구성 요소와 같은 인터페이스 또는 추상 클래스를 구현한다.
• Decorator는 Component의 상태를 확장할 수 있다.
• ConcreteDecorator에는 데코레이터가 감싸고 있는 Component 객체용 인스턴스 변수가 있다.
• 데코레이터가 새로운 메소드를 추가할 수도 있다. 하지만 일반적으로 새로운 메소드를 추가하는 대신 Component에 원래 있던 메소드를(호출 전이나 호출한 후에) 별도의 작업으로 처리해서 새로운 기능을 추가한다.

---

☕ Beverage 클래스 장식하기

• HouseBlend, Espresso, DarkRoast, Decaf: 커피 종류마다 구성 요소를 나타내는 구상 클래스를 하나씩 만들었다.
• Milk, Mocha, Soy, Whip: 각각의 첨가물을 나타내는 데코레이터. cost()와 getDescription()도 구현해야 한다.

이 클래스 다이어그램을 보면 CondimentDecorator에서 Beverage 클래스를 확장하고 있다. 그러면 상속 아닐까? 상속이다. 데코레이터 패턴에서는 상속을 사용해서 형식을 맞추는 것이지, 상속으로 행동을 물려받는 것이 아니다. 원래 있던 구성 요소가 들어갈 자리에 자기가 들어갈 수 있어야 하니까 데코레이터 객체는 자신이 감싸고 있는 객체와 같은 인터페이스를 가져야 한다.

그렇다면 행동은 어디서 올까?

어떤 구성 요소를 가지고 데코레이터를 만들 때 새로운 행동을 추가한다. 새로운 행동은 슈퍼클래스로부터 행동을 상속받는 것이 아니라 객체를 _구성_해서 얻는 것이다. 따라서 음료에 첨가물을 다양하게 추가해도 유연성을 잃지 않을 수 있다.

구성 요소의 형식만 상속하면 되는 거라면 Beverage 클래스를 왜 인터페이스로 만들지 않고 추상 클래스로 만들었을까?

원래 데코레이터 패턴에서는 특정한 추상 구성 요소를 지정할 필요가 없지만, 기존 코드를 고치는 일은 될 수 있으면 피하는 것이 좋다. 기존 코드에서 추상 클래스를 사용하고 있었으므로, 추상 클래스를 써도 되는 상황이라면 그냥 추상 클래스만 가지고 작업을 하는 게 나을 수도 있다.

---

☕ 데코레이터 패턴 적용 연습

“두유를 추가하고 휘핑크림을 얹은 더블 모카 한 잔 주세요!”
어떻게 하면 좋을지 그려 보자.

• 제일 먼저 Whip의 cost() 호출
• Whip에서 Mocha에 있는 cost() 호출
• Mocha에서 그 안쪽에 있는 다른 Mocha의 cost() 호출
• Mocha에서 Soy에 있는 cost() 호출
• 마지막 데코레이터인 Soy에서 DarkRoast의 cost() 호출

• DarkRoast의 cost()에서 89센트 리턴. — cost() 메소드는 스택에서 제거됨.
• Soy의 cost()에서 89센트 + 15센트 리턴. — cost() 메소드는 스택에서 제거됨.
• Mocha의 cost()에서 89센트 + 15센트 + 20센트 리턴. — cost() 메소드는 스택에서 제거됨.
• Mocha의 cost()에서 89센트 + 15센트 + 20센트 + 20센트 리턴. — cost() 메소드는 스택에서 제거됨.
• Whip의 cost()에서 89센트 + 15센트 + 20센트 + 20센트 + 10센트 리턴. — cost() 메소드는 스택에서 제거됨.

---

☕ 커피 주문 시스템 코드 만들기

✅ 베이스 클래스 준비

// 1️⃣ 음료의 기본 클래스 (추상 클래스)
abstract class Beverage {
  protected description: string = "알 수 없는 음료";

  getDescription(): string {
    return this.description;
  }

  abstract cost(): number;
}

// 2️⃣ 데코레이터 기본 클래스 (Beverage를 확장하는데, 음료를 감쌀 수 있도록 만듦)
abstract class CondimentDecorator extends Beverage {
  abstract getDescription(): string;
}

✅ 음료 코드 구현

• 음료를 설명하는 문자열을 설정하고 cost() 메소드를 꼭! 구현해야 한다.

// 3️⃣ 실제 음료 서브클래스 (다크 로스트, 하우스 블렌드)
class Espresso extends Beverage {
  constructor() {
    super();
    this.description = "에스프레소";
  }

  cost(): number {
    return 1.99;
  }
}

class HouseBlend extends Beverage {
  constructor() {
    super();
    this.description = "하우스 블렌드 커피";
  }

  cost(): number {
    return 0.89;
  }
}

✅ 첨가물 코드 구현하기

// 4️⃣ 구체적인 추가 기능 (휘핑크림, 우유, 샷 추가 등)
class Mocha extends CondimentDecorator {
  constructor(private beverage: Beverage) {
    super();
  }

  getDescription(): string {
    return this.beverage.getDescription() + ", 모카";
  }

  cost(): number {
    return this.beverage.cost() + 0.20;
  }
}

✅ 커피 주문 시스템 코드 테스트

// 5️⃣ 사용 예제
let myCoffee: Beverage = new Espresso();  // 에스프레소 주문
console.log(myCoffee.getDescription() + `: $${myCoffee.cost()}`);  
// "에스프레소: $1.99"

myCoffee = new Mocha(myCoffee);  // Mocha로 감싸기
myCoffee = new Mocha(myCoffee);  // Mocha 샷 추가
myCoffee = new Whip(myCoffee);   // Whip으로 감싸기
console.log(myCoffee.getDescription() + `: $${myCoffee.cost()}`);  
// "에스프레소, 모카, 모카, 휘핑크림: $4.29"