[스위프트 디자인패턴] 전략 패턴(Strategy Pattern)

전략 패턴(Strategy Pattern)

전략 패턴은 알고리즘의 집합(Algorithm Family)을 사용하는 행위 패턴입니다. 여러 알고리즘을 각각 객체로 캡슐화하고, 동일한 목적을 하는 알고리즘들을 하나의 인터페이스로 묶습니다. 그러면 이 알고리즘들이 클라이언트 객체에서 교체되면서 사용할 수 있게 됩니다. 따라서 알고리즘이 클라이언트 객체에 독립적으로 구성되기 때문에 느슨한 연결(Decoupling)을 만들 수 있죠.

 

느슨하게 연결된다는 것은 클라이언트 객체가 알고리즘이 변하게 될 때, 영향을 받지 않게 된다는 것을 의미합니다. 만약 어떤 알고리즘이 수정되어야 한다면, 캡슐화된 해당 알고리즘만 수정하게 되고, 내부적으로 어떻게 수정되고 어떻게 구현되어 있는지 클라이언트 객체는 알지 못합니다.

 

예를 들어봅시다.

어떤 문자열이 들어왔을 때, 조건을 검사해주는 Validator 객체가 있다고 해볼게요. 처음에는 별 문제가 없겠지만, 만약 추가적인 요구사항이 생겨서 알고리즘이 추가된다면 어떨까요? 그때 우리는 아마도 Validator 객체에 새로운 알고리즘을 추가하겠죠. 

 

하지만 이런 방법은 개방 폐쇄 원칙(OCP)에 어긋납니다. 기존 객체에 변경사항이 생기기 때문이죠.

 

 

따라서 전략 패턴은 클라이언트 객체는 알고리즘 집합의 인터페이스를 가지고, 구체적인 알고리즘을 필요에 따라 주입하게 합니다.

 

이런 디자인 패턴을 사용하면 만약 새로운 요구사항에 따라 Validator가 아스키 코드를 검사하게 된다고 하더라도 아래와 같이 구성하는 것을 통해서 개방 폐쇄 원칙을 지킬 수 있습니다.

 

구현해보기

그럼 위에서 정리한 컨셉을 그대로 구현해보겠습니다.

 

먼저, 클라이언트 객체와 알고리즘의 인터페이스가 될 프로토콜을 정의할게요.

 

protocol Validatable {
    func validate(text: String) -> Bool
}

protocol Validator {
    var validationStrategy: Validatable { get set }
    func validate(text: String) -> Bool
}

Validatable 프로토콜은 알고리즘의 인터페이스가 될 프로토콜입니다. validate 메서드를 정의하고 있고, 인자로 문자열을 받으면 적절한 알고리즘을 수행한 뒤에 Bool 타입 값을 반환하도록 강제하고 있어요. 전략에 해당하는 각 알고리즘들은 이 프로토콜을 채택해 validate를 구현하면 되겠죠.

 

Validator 프로토콜은 클라이언트 객체의 내부에 대한 인터페이스를 제공하는 프로토콜입니다. validationStrategy 프로퍼티를 통해서 Validatable 타입, 즉, 검증에 사용할 알고리즘의 인터페이스를 가지게 됩니다. 그리고 Validator도 validation 메서드를 가지는데요, 이번에는 실제로 사용자가 호출하고 결과를 반환하게 될 메서드입니다.

 

final class StringValidator: Validator {
    var validationStrategy: Validatable
    
    init(strategy: Validatable) {
        self.validationStrategy = strategy
    }
    
    func change(strategy: Validatable) {
        self.validationStrategy = strategy
    }
    
    func validate(text: String) -> Bool {
        return validationStrategy.validate(text: text)
    }
}

이제 클라이언트 객체의 구체타입을 정의했습니다. StringValidator는 Validator 프로토콜을 채택해 구현하고 있는데요, validate 메서드를 통해 검증 알고리즘을 수행하고, change 메서드를 통해 현재 사용하는 알고리즘을 다른 알고리즘으로 변경할 수 있게 합니다. 

 

여기서 가장 중요한 validate 메서드를 다시 볼게요.

func validate(text: String) -> Bool {
    return validationStrategy.validate(text: text)
}

validate 메서드는 내부에 어떤 알고리즘도 가지지 않아요. 대신 자신이 가지고 있는 알고리즘 전략(validationStrategy)가 가진 알고리즘을 실행해서 그 결과를 그대로 반환하죠. 알고리즘의 구현과 그 알고리즘을 사용하는 객체가 완전하게 분리된 것입니다.

 

그럼 알고리즘을 구현해주어야겠죠?

class NumberValidator: Validatable {
    func validate(text: String) -> Bool {
        return text.allSatisfy({ $0.isNumber })
    }
}

class LengthValidator: Validatable {
    func validate(text: String) -> Bool {
        return text.count < 10
    }
}

일단 Validatable을 채택하는 두 개의 타입을 만들었어요. 그리고 각각 문자열의 모든 문자가 숫자인지 확인하는 알고리즘과 문자열의 길이가 10 미만인지 확인하는 알고리즘을 정의해주었습니다.

 

let validator = StringValidator(strategy: LengthValidator())
print(validator.validate(text: "12345678910")) // false

validator.change(strategy: NumberValidator())
print(validator.validate(text: "12345678910")) // true

클라이언트 객체를 사용할 때는 생성자를 통해 사용할 알고리즘을 주입하거나, change 메서드를 통해 사용할 알고리즘을 변경합니다. 

 

새로운 전략의 추가

꽤 간단하게 전략 패턴을 구현할 수 있었는데요, 이번에는 위에서 정리하면서 이야기했던대로 새로운 요구사항이 하나 추가되었다고 해보겠습니다. 이번에는 StringValidator가 문자열의 모든 문자가 아스키 코드로 표현이 가능한지 확인하는 알고리즘이 추가되어야 해요.

 

class AsciiValidator: Validatable {
    func validate(text: String) -> Bool {
        return text.allSatisfy({ $0.isASCII })
    }
}

따라서 Validatable을 채택하는 알고리즘을 캡슐화한 객체를 새로 하나 만들고,

 

validator.change(strategy: AsciiValidator())
print(validator.validate(text: "12345678910")) // true

클라이언트 객체에 주입해주기만 하면 새로운 요구사항을 만족시킬 수 있습니다. 만약 추가해야하는 알고리즘이 수십가지라면 기존 객체를 수정하지 않고 쉽게 알고리즘을 추가할 수 있겠죠.

 

만약 모든 알고리즘을 한번에 수행해야한다고 하더라도 아래처럼 처리할 수 있으니까요.

func validateAll(text: String) -> Bool {
    let strategies: [Validatable] = [LengthValidator(), NumberValidator(), AsciiValidator()]
    return strategies.filter({ strategy in
        return StringValidator(strategy: strategy).validate(text: text)
    }).isEmpty
}

print(validateAll(text: "12345678910")) // false

 

정리

전략 패턴은 알고리즘들을 캡슐화해서 클라이언트 객체로부터 분리하고, 같은 목적의 알고리즘들을 하나의 인터페이스로 묶어 객체가 필요에 따라 알고리즘을 교체할 수 있게 하는 디자인 패턴이었습니다. 

 

알고리즘과 클라이언트가 완전히 분리되어 있기 때문에 변경과 확장에 유연하고 OCP를 따르는 디자인 패턴입니다. 사실 따지고 보면 SRP, DIP, SIP, LSP도 모두 따르고 있어요.

 

알고리즘의 수행을 캡슐화된 알고리즘 객체에, 알고리즘의 선택은 클라이언트 객체로 나누고 있어 단일 책임 원칙(SRP)을 따르고,

클라이언트 객체는 알고리즘 인터페이스에 의존하기 때문에 의존성 역전 원칙(DIP) 따르게 됩니다.

알고리즘의 각 인터페이스는 Alogrithm Family를 표현하기 때문에 인터페이스 분리 원칙(SIP)도 따르고,

위 예제에서는 LSP가 명확히 나타나지는 않지만, 언제나 같은 알고리즘 인터페이스를 사용하게 되기 때문에 하위 타입과 상위 타입이 치환 가능한 리스코프 치환 원칙(LSP)을 따르게 됩니다.

 

전략 패턴은 한 객체가 비슷한 목적을 가지는 여러 알고리즘을 런타임에 선택적으로 사용하게 될 때 분기 처리를 줄이는 방법으로 사용해볼 수 있을 것 같아요.