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

데코레이터 패턴(Decorator Pattern)

Decorator pattern attatches additional repsonsibilities to an object dynamically.

데코레이터 패턴이 무엇일까요? 일반적으로 우리는 어떤 객체에 메시지를 보내고(메서드 호출) 그에 대한 응답으로 어떤 동작의 결과를 얻게됩니다. 데코레이터 패턴은 메시지를 처리하는 메서드의 동작을 추가해 런타임에 해당 객체의 코드를 수정하지 않고도 새로운 기능을 수행하는 것이 가능하게 하는 패턴입니다.

런타임 타임에 새로운 동작을 추가할 수 있도록 하기 위해서 데코레이터 패턴은 객체를 한번 감싸는 래퍼 객체를 두게 됩니다.

이렇게요! Concrete 객체는 원래 우리가 사용하려는 타입이고, Wrapper는 Concrete와 같은 타입이면서 새로운 기능을 추가하는 객체입니다. 하지만 외부에서 메서드를 호출할 때는 concrete가 가진 메서드를 호출하는 것 처럼 보이죠. 

무슨 말인지 잘 모르겠죠..? 예제와 함께 왜 데코레이터 패턴이 왜 필요한지 다시 고민해봅시다.

 

서브웨이 구현해보기

여러분이 샌드위치 가게인 서브웨이를 코드로 옮겨보려고 노력해본다고 해볼게요. 기본 메뉴도 있겠지만 서브웨이의 묘미는 원하는 재료를 마음대로 섞어서 금액을 지불하는 것이겠죠. 그럼 먼저 기본적인 클래스를 만들어봅시다.

import Foundation

protocol Sandwich: CustomStringConvertible {
    func cost () -> Int
}

class OriginalSandwich: Sandwich {
    var description: String {
        return "OriginalSandwich"
    }
    
    func cost() -> Int {
        return 3000
    }
}

class VeganSandwich: Sandwich {
    var description: String {
        return "VeganSandwich"
    }
    
    func cost() -> Int {
        return 2500
    }
}

Sandwich 프로토콜을 하나 만들고, 기본 샌드위치와 비건 기본 샌드위치 타입을 만들어주었어요. 지금은 두 종류의 샌드위치가 있는데요, 서브웨이에서 하듯이 재료가 더 추가되어서 종류가 많아지면 어떻게 될까요? 

 

protocol Sandwich: CustomStringConvertible {
    func cost () -> Int
}

class OriginalSandwich: Sandwich {
    var description: String {
        return "OriginalSandwich"
    }
    
    func cost() -> Int {
        return 3000
    }
}

class VeganSandwich: Sandwich {
    var description: String {
        return "VeganSandwich"
    }
    
    func cost() -> Int {
        return 2500
    }
}

class meatballSandwich: Sandwich {
    var description: String {
        return "meatballSandwich"
    }
    
    func cost() -> Int {
        return 3500
    }
}

class avocadoSandwich: Sandwich {
    var description: String {
        return "avocadoSandwich"
    }
    
    func cost() -> Int {
        return 4500
    }
}

단일 책임 원칙을 지키기 위해서 이렇게 잘게 세부 타입을 더 만들어주는 방법도 있겠지만, 종류가 많으면 많을수록 클래스의 개수가 늘어납니다. 모든 조합에 대해서 새 클래스를 만들 수는 없으니까요. 좋은 방법은 아닌 것 같죠? 

또 다른 방법으로는 모든 재료를 정의해두고 Boolean으로 사용할 재료를 바꿔줄 수도 있겠죠.

import Foundation

protocol Sandwich: CustomStringConvertible {
    var hasAvocado: Bool { get set }
    var hasMeatBall: Bool { get set }
    func cost () -> Int
}

extension Sandwich {
    mutating func toggleAvocado() {
        self.hasAvocado.toggle()
    }
    
    mutating func toggleMeatBall() {
        self.hasMeatBall.toggle()
    }
}

class OriginalSandwich: Sandwich {
    var hasAvocado: Bool
    var hasMeatBall: Bool
    
    var description: String {
        return "OriginalSandwich"
    }
    
    init(hasAvocado: Bool, hasMeatBall: Bool) {
        self.hasAvocado = hasAvocado
        self.hasMeatBall = hasMeatBall
    }
    
    func cost() -> Int {
        return 3000
    }
}

class VeganSandwich: Sandwich {
    var hasAvocado: Bool
    var hasMeatBall: Bool
    
    var description: String {
        return "VeganSandwich"
    }
    
    init(hasAvocado: Bool, hasMeatBall: Bool) {
        self.hasAvocado = hasAvocado
        self.hasMeatBall = hasMeatBall
    }
    
    func cost() -> Int {
        return 2500
    }
}

하지만 이 방법 역시 조합해야할 재료가 수십가지가 된다면 생성자가 너무 복잡해지고, 금액을 계산할 때 필연적으로 분기처리를 진행하게 됩니다. 또, 비건 샌드위치의 경우에는 hasMeatBall이라는 메서드를 절대 사용하지 않는데도, 인터페이스에 미트볼이 있다는 이유로 hasMeatBall이라는 메서드를 가지게 됩니다. 즉, 인터페이스 분리 원칙(ISP)을 위배하게 되죠.  결정적으로 새로운 재료가 추가될 때마다 구체 타입과 추상 클래스를 모두 수정해주어야하기 때문에 개방 폐쇄 원칙(OCP)를 따르지 않는 구조의 코드가 됩니다. 

데코레이터 패턴은 이런 상황에서 유연하게 새로운 재료를 추가하고, 런타임에도 동적으로 재료를 추가해서 기존 객체의 코드를 수정하지 않은 채로 새로운 기능이나 정보를 객체에 추가할 수 있게 합니다. 

 

데코레이터 패턴 적용하기

그럼 위 예제에 데코레이터 패턴을 적용해서 좀 더 나은 구조를 만들어볼게요.

먼저 데코레이터 패턴을 정리해보죠. 가장 최상위에 있는 Component는 우리가 재료를 추가할 객체의 추상클래스입니다. 우리의 예제에서는 Sandwich가 되겠죠? 그리고 이 추상화된 클래스를 구현하는 구현체가 ConcreteComponent, 즉 우리의 예제에서는 OriginalSandwich와 VeganSandwich가 됩니다. 

우리는 이 구체 타입에 Decorator를 통해 재료를 추가해주려고 해요. 이 재료가 될 타입들의 추상 클래스가 Decorator입니다. 그림에서 Decorator가 Component를 상속하는 것과 동시에 Component를 소유하고 있는데요, 이유에 대해서 고민해봅시다. 

먼저, 우리가 금액을 계산하기 위해 cost 메서드를 호출한다고 해볼게요, 그럼 기본 타입(OriginalSandwich, VeganSandwich)에 Decorator를 통해 추가한 재료들의 가격이 추가되어야 합니다. 그렇지만 우리는 Sandwich 타입에 따로 재료에 대한 목록을 가지고 있지는 않아요. 단일 책임 원칙과 개방 폐쇄 원칙을 지키기 위해서요. 

그래서 Decorator의 각 타입들은 Sandwich 타입을 소유하고, 동시에 Sandwich에서 강제하는 메서드들을 구현해서 재귀적으로 원하는 결과를 얻을 수 있도록 해야합니다.

따라서 금액을 얻기 위한 로직은 따라서 이렇게 되겠죠. 메서드 요청이 들어가면 가장 중심에 있는 ConcreteComponent까지 도달하고, 이를 base case로 삼아서 각 재료의 가격들을 더해 최종적인 금액을 구하게 되는 것입니다. 이런 방식으로 구성한다면 각 재료들은 다른 재료들의 상황에 신경쓸 필요도 없고, Concrete Component도 자신에게 어떤 재료가 추가되는지 알 필요가 없어집니다. 

그럼 구현해볼까요?

데코레이터 패턴 구현하기

먼저 기능들을 추가할 수 있도록 해주는 데코레이터부터 만들어봅시다.

protocol Decorating: Sandwich {
    var sandwich: Sandwich { get set }
}

데코레이터 프로토콜을 만들었고, 내부에는 Sandwich 타입의 변수를 가지도록 인터페이스를 구성했어요. 데코레이터 프로토콜은 데코레이터를 적용할 구체적인 객체의 타입을 상속하거나 채택해야하고, 동시에 같은 타입의 인스턴스를 멤버로 가지고 있어야 합니다. 

그리고 이 프로토콜을 채택하는 재료의 역할을 할 Concrete Decorator는 아보카도와 미트볼이 되겠죠.

class Avocado: Decorating {
    var sandwich: Sandwich
    var description: String {
        return self.sandwich.description + " + Avocado"
    }
    
    init(sandwich: Sandwich) {
        self.sandwich = sandwich
    }
    
    func cost() -> Int {
        return self.sandwich.cost() + 1000
    }
}

class MeatBall: Decorating {
    var sandwich: Sandwich
    var description: String {
        return self.sandwich.description + " + MeatBall"
    }
    
    init(sandwich: Sandwich) {
        self.sandwich = sandwich
    }
    
    func cost() -> Int {
        return self.sandwich.cost() + 1500
    }
}

각 재료들은 생성자로 Sandwich 타입을 받아요. 하지만 이 타입은 재료를 추가할 대상인 Concrete Component 뿐만 아니라, Decorator도 가지고 있기 때문에 Decorator를 생성자로 전달하는 것도 가능하죠. 왜 이렇게 하는지 잘 이해가 안되어도 괜찮아요..! 잠시 후에 생성자를 사용해보면 명쾌해집니다!

각 재료들이 구현하는 메서드와 연산 프로퍼티는 생성자로 받은 Sandwich 타입이 가진 동명의 메서드/연산 프로퍼티를 호출하고 그 반환 값에 자신의 상태 값을 추가해주는 방식입니다. 

같은 추상 클래스를 구현하고 있지만, 가장 기본 타입이 될 Concrete Component는 조금 다르게 구현을 합니다.

class OriginalSandwich: Sandwich {
    var description: String {
        return "OriginalSandwich"
    }
    
    func cost() -> Int {
        return 3000
    }
}

class VeganSandwich: Sandwich {
    var description: String {
        return "VeganSandwich"
    }
    
    func cost() -> Int {
        return 2500
    }
}

재귀를 종료할 base case가 필요하기 때문이에요. Concrete Component의 경우에는 자신의 값만 반환하고 종료됩니다. 여기서 반환되는 값을 기준으로 재료들이 가진 메서드에서 각 재료들의 값이 추가되어서 처리되는 것이죠. 

이제 인스턴스를 만들어봅시다!

let avocadoMeatBallSandwich = MeatBall(sandwich: Avocado(sandwich: OriginalSandwich()))

print(avocadoMeatBallSandwich.cost())
print(avocadoMeatBallSandwich)

아까 Sandwich 타입을 Decorator가 따르고 있었죠? 그 이유는 새로운 재료가 추가된 Concrete Component를 생성자에 넣어주는 것이 가능하도록 하기 위해서입니다. 이렇게 할 수 없다면 데코레이터는 인스턴스마다 딱 하나만 추가할 수 있을거에요.

순서대로 미트볼, 아보카도 인스턴스를 만들어주고 마지막에 Concrete Component의 인스턴스를 주면,

이 그림이 그대로 구현이 됩니다.

출력 결과도 우리가 의도한대로였어요. 

 

새로운 재료의 등장

만약 런타임에 "토마토" 라는 재료를 추가해주어야 하는 상황이 생겼다면 어떨까요? 이런 상황에서 데코레이터 패턴을 유용하게 사용할 수 있게됩니다.

먼저 Decorator 프로토콜을 채택하는 토마토 타입을 만들겠습니다.

class Tomato: Decorating {
    var sandwich: Sandwich
    var description: String {
        return self.sandwich.description + " + Tomato"
    }
    
    init(sandwich: Sandwich) {
        self.sandwich = sandwich
    }
    
    func cost() -> Int {
        return self.sandwich.cost() + 500
    }
}

간단하게 추가가 가능하겠죠? 그리고 기존에 만들었던 미트볼 아보카도 샌드위치에 토마토를 넣어줍니다.

let tomatoAdded = Tomato(sandwich: avocadoMeatBallSandwich)
print(tomatoAdded.cost())
print(tomatoAdded)

기존 객체는 그대로 둔 채로 토마토를 추가한 객체를 손쉽게 만들어낼 수 있습니다. 새로운 재료가 자주 추가되거나, 동적으로 기존 객체에 새로운 상태를 만들어내고 싶다면, 데코레이터 패턴을 사용해 OCP를 따르면서도 유연하게 변경에 대처할 수 있는 객체를 만들 수 있습니다.

 

오늘도 읽어주셔서 감사합니다!