[Design Pattern] Builder 패턴을 활용해보자

얼마전에 친구가 Builder 패턴에 대해 어떻게 생각하냐고 물어봐서... 어라라? 그게 뭐지? Σ(； ･`д･´) 하고 간단하게 서칭을 해봤습니다.

근데 엥 ? 이거 어디서 많이 본 모습인데... ?! 

public class TestBuilderPattern {
 
    public static void main(String[] args) {
        Computer comp = new Computer.ComputerBuilder("500 GB", "2 GB")
                .setBluetoothEnabled(true)
                .setGraphicsCardEnabled(true)
                .build();
    }
 
}

(코드 출처는 요기)

iOS 개발 하시는 분들은 익숙하실 SwiftUI의 냄새가 나는 것 같지 않나요 ?! 

아직 스유 공부를 제대로 안해봐서 잘 모르지만 아무래도 생긴건 정말 비슷한 것 같습니다!

이렇게 된 김에 한 번 공부를 제대로 해보면 좋겠다 & 디자인 시스템 구축에 잘 사용해볼 수 있을 것 같아서 한 번 알아보도록 하겠습니다 ┌(˘⌣˘)ʃ

(왜 디자인 시스템 구축에 잘 사용해볼 수 있을 것 같냐구요 ... ?! 개인적인 의견이지만 그건 뒤에서 ㅎㅎ ~)

 

아래의 내용은 Refactoring.guru의 디자인 패턴에 뛰어들기 책을 읽고 정리한 내용입니다 ₍₍ (ง ˘ω˘ )ว ⁾⁾

 

Builder 패턴

저는 최근에 정말 많이 이런 상황을 겪었는데요

하나의 클래스로 원하는 상황을 모두 표현할 수 있는 다양한 객체를 만들려고 하다보면... 해당 클래스의 initializer 파라미터가 기하급수적으로 늘어나는 경험 혹시 다들 없으신가요?

가장 기억에 남는 예시로는 작년에 만들었던 커스텀 alert ViewController가 생각납니다.

    func setViewData(type: CustomAlertType,
                     buttonType: CustomAlertButtonType,
                     buttonStyle: iMAlertButtonStyle,
                     title: String? = nil,
                     bodyMessage: String,
                     subMessage: String? = nil,
                     subMessageHandler: (() -> Void)? = nil,
                     okButtonTitle: String = Strings.Common.confirm,
					 cancelButtonTitle: String? = Strings.Common.cancel,
                     okButtonHandler: (() -> Void)? = nil,
                     cancelButtonHandler: (() -> Void)? = nil,
                     isNeedNetworkCheck: Bool = false,
					 textAlignment: NSTextAlignment = .center
    )

 

하나의 ViewController로 다양한 상황을 모두 표현해줘야 하다보니 이렇게 많은 파라미터들이 추가되기 시작하더라구요.

그리고 보시면 default value로 nil이 들어가있는 경우가 많은데 그만큼 해당 파라미터들은 사용되지 않는다는걸 알 수 있어요.

그래서 Builder 패턴의 첫 문장을 읽고 아 이거다 ! 싶었답니다.

 

이러한 상황을 피하기 위해 각 특성에 맞는 빌더를 사용하여 객체를 생성하는 것이 바로 빌더 패턴입니다.

그리고 이러한 빌더들을 조종하는 객체가 하나 더 있는데 바로 디렉터입니다.

이 디렉터는 빌더 내부의 메서드가 동작하는 순서를 정하고 명령을 내리는 객체입니다.

조금 더 자세한 설명은 뒤에서 더 해볼게요!

 

예시

예를 들어 집을 만드는 HouseBuilder가 있고 내부에 가능한 메서드로는 makeDoors(), makeWalls(), makeRoof(), makeSwimmingPool() 가 있다고 해봅시다.

가장 기본적인 집을 건설할 때는 

let builder = HouseBuilder()
builder.makeDoors()
	.makeWalls()
        .makeRoof()

 

이렇게 필요한 메서드들만 골라서 실행시켜주면 됩니다. 모든 집에 수영장이 있을 필요는 없잖아요 ?!

이렇듯이 Builder 패턴에서는 원하는 객체 생성에 필요한 메서드만 호출하면 된다는 특징이 있습니다.

그리고 하나의 빌더 객체에 연속적으로 메서드를 실행하기 때문에 객체가 완성 끝~! 되기 전까지 다른 객체들은 생성되는 객체에 접근할 수 없다는 특징도 있습니다.

 

그리고 집은 돌로 지을 수도 있고, 나무로도 지을 수 있고, 철로도 지을 수 있잖아요 ? 하지만 기본적인 문을 만들거나 벽을 세우고 지붕을 올리는 과정은 다 필수적이죠. 재료만 다를 뿐!

그렇기 때문에 HouseBuilder Protocol을 선언해둔 뒤 StoneHouseBuilder class에서 이를 채택하는 형식으로 진행할 수 있습니다!

protocol HouseBuilder {
    func makeDoors()
    func makeWalls()
    func makeRoof()
    func makeSwimmingPool()
}

class StoneHouseBuilder: HouseBuilder {
    func makeDoors() { 돌문 만들기... } 
    func makeWalls() { 돌벽 만들기... } 
    func makeRoof() { 돌지붕 만들기... } 
    func makeSwimmingPool() { 돌로 된 수영장 만들기... } 
}

 

이런 식으로 구현할 수 있을 것 같습니다!

이런 구조를 활용하기 위해서는 Builder를 호출하는 Director 혹은 클라이언트 코드가 특정 Builder 클래스(StoneHouseBuilder처럼)가 아닌 HouseBuilder 프로토콜을 사용하도록 구현해야겠죠?

Director

변태같지만 너무 맘에 드는 짤이라 .. 가져왔습니다

 

위에서 디렉터는 빌더 내부의 메서드가 동작하는 순서를 정하고 명령을 내리는 객체입니다. 라고 했었는데

이 디렉터에 대해서 조금 더 알아보겠습니다.

 

빌더가 직접 만드는 구현 과정을 제공하고 있다면 디렉터 클래스는 제작 순서를 정의하는 역할을 담당하고 있습니다.

빌더는 문 만드는 법, 벽 만드는 법, 지붕 만드는 법은 알지만 그 순서에 대해서는 아무것도 알지 못합니다.

벽 없이 지붕을 올릴 수는 없는 법이잖아요? 이런 빌더를 디렉터에게 넘기면

디렉터가 빌더에게 벽 먼저 만들고! 문 만들고 그리고 지붕 올려! 이렇게 명령을 하게 됩니다.

 

하지만 디렉터 클래스는 필수는 아닙니다! 왜냐면 위의 예시 파트만 봐도 디렉터없이 빌더만으로도 잘 진행했잖아요?

빌더한테 클라이언트가 직접 하나하나 순서를 알려주면서 만드는 것도 가능합니다.

하지만 디렉터 클래스를 활용한다면 몇가지 장점이 있습니다.

 

먼저 재사용하기 쉽습니다.

디렉터 클래스 없이 빌더만 사용한다면 집을 하나 만들고자 하면 벽 먼저 만들고! 문 만들고 그리고 지붕 올려! 이 과정을 매번 알려줘야 빌더는 일할 수 있습니다. 만약 과정이 더 길어지고 여러번 사용된다면 반복되는 코드가 많이 늘어나겠죠?

하지만 디렉터 클래스를 사용한다면 기본 집 만들어줘~ 한번만 얘기하면 이 내부에 벽 먼저 만들고! 문 만들고 그리고 지붕 올려! 이 내용이 포함돼있을 것 이기 때문에 훨씬 간편하게 사용할 수 있습니다. 중복되는 코드도 훨씬 줄어들거구요!

 

두번째로는 외부로부터 내부 구현 소스를 숨길 수 있습니다.

사실 집을 만들 때 어떤 재료들이 필요한지, 어떤 과정들을 거쳐야하는지 클라이언트가 알 필요가 있을까요...? 

그냥 명령만 내리면 알아서 집을 만들어줬음.. 하는게 우리의 맘이잖아요?

디렉터 내부로 빌더의 로직을 넣으면서 캡슐화를 시킴으로써 결합도를 보다 낮출 수 있다고 생각합니다!

하지만 언제든 오버엔지니어링에 대한 경각심을 갖고 있는 것도 중요하다고 생각하기 때문에 만약 너무 복잡한 빌더 로직이 없다면 ? 디렉터가 과연 지금 필요한가? 에 대한 고민도 늘 해보고 결정하는 것이 좋다고 생각합니다.

 

코드

사실 저는 개념만 볼 때보다 코드로 보는게 훨씬 이해가 잘됐기 때문에 코드로 한 번 보겠습니다!

 

• 생성할 Product

class Product1 {

    private var parts = [String]()

    func add(part: String) {
        self.parts.append(part)
    }

    func listParts() -> String {
        return "Product parts: " + parts.joined(separator: ", ") + "\n"
    }
}

 

이러한 Product1 클래스가 있고 이 클래스에 대해 많은 configuration이 필요한 상황이라고 가정해보겠습니다.

 

• Builder protocol

protocol Builder {

    func producePartA()
    func producePartB()
    func producePartC()
}

 

Builder가 반드시 가져야하는 메서드들을 선언한 Builder protocol이 있고

 

• Builder 구현체

class ConcreteBuilder1: Builder {

    private var product = Product1()

    func reset() {
        product = Product1()
    }

    func producePartA() {
        product.add(part: "PartA1")
    }

    func producePartB() {
        product.add(part: "PartB1")
    }

    func producePartC() {
        product.add(part: "PartC1")
    }

    func retrieveProduct() -> Product1 {
        let result = self.product
        reset()
        return result
    }
}

 

해당 프로토콜을 채택한 ConcreteBuilder1 클래스가 있습니다.

내부 코드를 보면 Builder 프로토콜 채택으로 인해 producePartA, B, C 메서드를 구현해줬습니다.

 

그리고 reset(), retrieveProduct() 메서드가 있습니다.

먼저 retrieveProduct를 보면 지금까지 생성된 product를 변수에 저장해두고 reset 메서드를 호출해서 초기화시켜줍니다. 그리고 변수에 저장해뒀던 result를 리턴해주고 있습니다.

 

retrieveProduct 메서드는 그냥 생성한 product를 리턴해주는 메서드인데 왜 프로토콜에 정의돼있지 않을까요?

생각해보면 Builder 프로토콜을 채택한 구현체 Builder들이 모두 동일한 인터페이스를 가진 객체를 생성하지 않을겁니다.

Builder라는 프로토콜은 단계를 명시해줄 뿐 그로 인해 만들어지는 결과물에는 제약을 걸지 않았기 때문이죠!

 

그렇기 때문에 Builder 프로토콜에 해당 메서드를 명시해주지 않은거죠. 

흠 근데 제네릭 메서드로 생성하면 아마 가능할 것 같긴하네요 🤔

protocol Builder<T> {
    func retrieveProduct() -> T
}

 

만약 이렇게 한다면... ?! 

 

그리고 reset 메서드도 호출해주고 있는데 보통 결과물을 하나 얻고나면 그 후에 초기상태부터 다시 건설할 것을 기대하기 때문에 reset 메서드를 호출하는 것 같네요.

이 맥락에서 defer를 활용해볼 수도 있을 것 같다는 생각이 듭니다!

 

• Director

class Director {

    private var builder: Builder?

    func update(builder: Builder) {
        self.builder = builder
    }

    func buildMinimalViableProduct() {
        builder?.producePartA()
    }

    func buildFullFeaturedProduct() {
        builder?.producePartA()
        builder?.producePartB()
        builder?.producePartC()
    }
}

 

그리고 Director class 입니다!

앞에서 언급했던 것 처럼 Director class는 concrete builder class 타입을 갖고 있지 않고 Builder protocol 타입을 갖고 있네요.

이로 하여금 Builder 프로토콜을 채택하고 있다면 모두 Director에서 활용할 수 있습니다. 그렇기 때문에 결과물로 어떤 타입이 나올지 모르는거구요! (만약 ConcreteBuilder1으로 타입이 제한돼있다면 결과물도 Product1으로 제한할 수 있었겠죠? 근데 그러면 원하는 객체 타입마다 Builder 뿐만 아니라 Director도 다 따로 생성해줘야함....🫠 매우 비효율적이라고 생각합니다!)

 

Director 클래스를 사용하다가 update 메서드로 builder를 변경해줄 수도 있구요

buildMinimalVisibleProduct(), buildFulllFeaturedProduct() 메서드 내부에는 해당 빌더 프로토콜에 선언된 메서드들을 원하는 순서대로 구성대로 실행시켜줌에 따라 생성 프로세스를 선언해둘 수 있습니다.

 

• Client

class Client {
    // ...
    static func someClientCode(director: Director) {
        let builder = ConcreteBuilder1()
        director.update(builder: builder)
        
        print("Standard basic product:")
        director.buildMinimalViableProduct()
        print(builder.retrieveProduct().listParts())

        print("Standard full featured product:")
        director.buildFullFeaturedProduct()
        print(builder.retrieveProduct().listParts())

        // Director 없이 product 생산하기!
        print("Custom product:")
        builder.producePartA()
        builder.producePartC()
        print(builder.retrieveProduct().listParts())
    }
    // ...
}

 

Client class는 내부에 director를 변수로 갖고 있는 상태입니다.

여기서 원하는 Builder 객체를 생성한 후 update 메서드로 해당 builder 객체를 장착합니다!

 

그 후 원하는 피쳐가 있따면? director에게 명령만 내리면 builder가 뚝딱뚝딱 일을 하게 되는거죠.

그리고 나서 결과물에 접근하고 싶을 때는 builder에게 직접 retrieveProduct 메서드를 호출하면 builder는 만들어둔 결과물을 리턴하고 자기 자신을 초기화시킵니다. 그렇게 다시 새로운 결과물 작업을 시작할 수 있는 상태가 되는거죠!

 

---

 

항상 반 정도만 이해하고 있었던 것 같은 빌더 패턴에 대해 조금 더 자세히 알아봤습니다!

이 내용을 토대로 디자인 시스템에 조금이나마 적용해보고자 하는데 만약에 성공한다면 후기글과 함께 다시 돌아오겠씁니다 。˃̵͈̑ᴗ❛。