[디자인패턴] 데코레이터 패턴 (Decorator Pattern)

 

1. 정의

💡 데코레이터 패턴 (decorator pattern)
객체에 추가적인 요건을 동적으로 첨가한다.
데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.

 

2. 예) 커피 주문 시스템

현재의 커피 시스템은 다음과 같이 되어 있다.

Beverage 라는 슈퍼클래스가 존재하고, 이 클래스를 상속하여 Espresso, Decaf 등 각 음료 클래스가 있다.

// Beverage 슈퍼 클래스
public abstract class Beverage {

    String description = "무슨 음료";
    // getter
    public String getDescription() {
        return description;
    }

    /** 가격은 다르므로 각 클래스에서 결정*/
    public abstract Integer cost();
}
// Beverage 를 상속받아 만든 Espresso 클래스
public class Espresso extends Beverage {
    public Espresso() {
        description = "에스프레소";
    }
    
    @Override
    public Integer cost() {
        return 3000;
    }
}
// 그외 음료 클래스..​

그런데, 새로운 주문방법을 도입한다고 한다. 고객이 원하는 각종 커스텀을 지원한다.

커피를 주문할때 원하는 시럽을 추가하거나 뺄수도, 우유를 두유로 바꾸는 등의 커스텀을 지원하며 가격은 모두 다르다.

• 에스프레소에 두유 추가해주시고 휘핑크림 얹어주세요. (EspressoWithSoyAndWhip 클래스 생성)
• 디카페인에 우유 추가해주세요. (DecafWithWholeMilk 클래스 생성)

이렇게 모든 요구사항을 조합하여 클래스를 만들면 그 수가 너무 많아진다. 다른 방법을 고안해야 한다.

슈퍼 클래스에 milk, soy, whip 등의 boolean 변수를 추가한후 하위 클래스에서 cost() 에서 더해주는 방식은 어떨까?

// 슈퍼클래스에 extra 를 boolean 변수로 정의하고 getter, setter 추가
public abstract class BeverageNo {

    String description = "무슨 음료";
    boolean milk;	// 우유 추가여부 변수
    boolean soy;	// 두유 추가여부 변수
    boolean whip;	// 휘핑 추가여부 변수
    boolean mocha;	// 모카 추가여부 변수

    // getter
    public String getDescription() {
        return description;
    }

    /** 추상 메소드 : 가격은 각 음료 클래스에서 결정 */
    public abstract Integer cost();

    // boolean 변수들의 getter, setter
    public boolean isMilk() {
        return milk;
    }
    public void setMilk(boolean milk) {
        this.milk = milk;
    }
    // soy, whip, mocha 의 getter, setter 는 생략..
}
// Beverage 를 상속받은 각 음료 클래스에서 boolean 변수로 cost() 계산한다.
public class Espresso extends BeverageNo {
    public Espresso() { description = "에스프레소"; }
    
    @Override
    public Integer cost() {
        Integer result = 3000;
        // 각 extra 변수를 확인하고 true 이면 가격을 더해준다
        if (milk) { result += 2000; }
        if (soy) { result += 3000; }
        if (mocha) { result += 1500; }
        if (whip)  { result += 1500; }
        return result;
    }
}
// 다른 음료들 생략..

이렇게 상속을 통해 각 구현 클래스에서 오버라이드로 구현하는 방식이 좋은 방식일까?

각 클래스마다 변경이 있으며 코드 중복도 발생하니 좋은 방법이라 볼 수 없다.

상속만 한다고해서 유연하고 관리가 쉬운 것이 아니다. 구성과 위임을 통해 실행 중에 행동을 상속 시키는 방법이 있다.

위와같이 서브클래스를 만드는 방식으로 행동을 상속받으면 그 행동은 컴파일을 할때 완전히 결정된다. 게다가 모든 서브클래스에서 같은 행동을 상속받아야한다. 그러나 구성을 통해 객체의 행동을 확장하면 실행중에 동적으로 결정할 수 있다.

객체를 동적으로 구성하면, 기존 코드를 고치는 대신 새 코드를 만들어 새 기능을 추가할 수 있다. 기존 코드를 바꾸지 않으므로 의도치 않은 버그를 방지할 수 있다.

 

■ 디자인 원칙 OCP (Open - Closed Principle)

📌 디자인 원칙 OCP (Open - Closed Principle)
클래스는 확장에 대해서는 열려 있어야하지만 코드 변경에 대해서는 닫혀 있어야 한다.

상속을 써서 음료가격과 Extra 가격을 합해 계산하는 방법은 클래스가 어마어마하게 많아지거나, 서브클래스에 적합하지않은 기능을 추가하게 될 수도 있다. 즉, 음료에서 시작해서 엑스트라로 장식(decorate) 하자!

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

 

1. Beverage 슈퍼클래스

public abstract class Beverage {

    String description = "무슨 음료";

    // getter
    public String getDescription() {
        return description;
    }

    /** 추상 메소드 : 서브클래스에서 가격결정 */
    public abstract Integer cost();
}

2. ExtraDecorator 클래스 (Beverage 를 꾸며주는 클래스)

public abstract class ExtraDecorator extends Beverage {
    Beverage beverage;
    public abstract String getDescription();
}

3. Espresso 클래스

public class Espresso extends Beverage {
    public Espresso() {
        description = "에스프레소";
    }

    @Override
    public Integer cost() {
        return 3000; // 에스프레소 기본 가격
    }
}

4. ExtraDecorator 를 상속받은 Soy 클래스, Mocha 클래스

// Soy
public class Soy extends ExtraDecorator {

    public Soy(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public Integer cost() {
        return beverage.cost() + 3000; // 기본이 되는 음료에 Soy 의 가격을 더해줌
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 두유"; // 설명에도 추가
    }
}
// Mocha
public class Mocha extends ExtraDecorator {

    public Mocha(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public Integer cost() {
        return beverage.cost() + 1500; // 음료에 Mocha 의 가격을 더해줌
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 모카"; // 설명에도 추가
    }
}

5. 기타 음료 및 Extra 클래스 생략..

6. 실행

@Slf4j
@Test
void espressoWithSoyAndMocha() {
    Beverage esp = new Espresso();
    Beverage withSoy = new Soy(esp);
    Beverage withSoyMocha = new Mocha(withSoy);
    log.info("espressoWithSoyAndMocha.getDescription() = {}", withSoyMocha.getDescription());
    log.info("espressoWithSoyAndMocha.cost() = {}", withSoyMocha.cost());
    Assertions.assertThat(withSoyMocha.cost()).isEqualTo(7500); // OK
}

@Test
void espressoWithSoy() {
    Beverage esp = new Espresso();
    esp = new Soy(esp);
    log.info("espressoWithSoy.getDescription() = {}", esp.getDescription());
    log.info("espressoWithSoy.cost() = {}", esp.cost());
    Assertions.assertThat(esp.cost()).isEqualTo(6000); // OK
}

출력결과

1. espressoWithSoyAndMocha() 결과
espressoWithSoyAndMocha.getDescription() = 에스프레소, 두유, 모카
espressoWithSoyAndMocha.cost() = 7500

2. espressoWithSoy() 결과
espressoWithSoy.getDescription() = 에스프레소, 두유
espressoWithSoy.cost() = 6000

 

■ UML Class Diagram

• Component : ConcreteComponent 와 Decorator 가 구현할 인터페이스
• ConcreteComponent : Component를 구현한 데코레이터로 꾸며줄 대상 객체
• Decorator : Component 를 가지고 있는 추상 클래스
  
  • Decorator 는 꾸며줄 대상이 있어야한다. 그러므로 Component 를 가지고 있어야하는데 각 데코레이터가 컴포넌트를 가지면 코드중복이 발생한다. 그래서 Decorator로 추상 클래스를 만들어 해결할 수 있다.
• ConcreteDecorator : Decorator 를 구현한 데코레이터 객체

 

---

참고
헤드 퍼스트 디자인 패턴 (Head First Design Patterns) - 에릭 프리먼,엘리자베스 롭슨,케이시 시에라,버트 베이츠