[디자인패턴] Builder - 복잡한 인스턴스를 조립한다

build: 일반적으로 구조를 갖춘 큰 구조물을 건축하거나 구축하는 것을 말한다.

Builder 패턴은 구조를 가진 인스턴스를 구축해 가는 패턴을 말한다. 

 

Builder 추상클래스, 인스턴스를 생성하기 위한 인터페이스(API)를 결정, 인스턴스의 각 부분을 만드는 메서드가 준비

ConcreteBuilder Builder의 인터페이스(API)를 구현하는 클래스, 실제 인스턴스 생성으로 호출되는 메서드가 여기에 정의

Director Builder의 인터페이스(API)를 사용하여 인스턴스를 생성한다, ConcreteBuilder 역에 의존하는 프로그래밍을 하지 않고 어떤 ConcreteBuilder 역이든 잘 작동하도록 Builder의 메서드만 사용한다.

Client 

 

public abstract class Builder {
    public abstract void makeTitle(String title);
    public abstract void makeString(String str);
    public abstract void makeItems(String[] items);
    public abstract void close();
}

public class Director {
    private Builder builder; // 포함 관계
    
    // 생성자
    public Director(Builder builder) {
        this.builder = builder;
    }
    
    // 문서를 만드는 메서드
    public void construct() {
        builder.makeTitle("Greeting");
        builder.makeString("일반적인 인사")
        builder.makeItems(new String[] {
            "How are you?",
            "Hello",
            "Hi"
        })
        builder.makeString("시간대별 인사")
        builder.makeItems(new String[] {
            "Good morning",
            "Good afternoon",
            "Good evening"
        });
        builder.close();
    }
}

Main 코드 중

if(args[0].equals("text")) {
    TextBuilder textbuilder = new TextBuilder();
    Director director = new Director(textbuilder);
    director.construct();
    String result = textbuilder.getTextResult();
    System.out.println(result);
} else if (args[0].equals("html")) {
    HtmlBuilder htmlbuilder = new HtmlBuilder();
    Director director = new Director(htmlbuilder);
    director.construct();
    String filename = htmlbuilder.getHtmlResult();
    System.out.println("HTML 파일 " + filename + "이 작성되었습니다.");
}

 

가만히 생각해 보기 좋았던 조언들

• 객체지향 프로그래밍에서는 '누가 무엇을 알고 있는가?'가 매우 중요하다. 즉, 어느 클래스가 어느 메서드를 사용할 수 있는지에 주의하여 프로그래밍할 필요가 있다.
• Director 클래스가 자신이 이용하는 Builder 클래스의 하위 클래스를 모르는 것은 매우 좋은 일이다. 왜냐하면 모르기에 교체할 수 있기 때문이다. 어떤 인스턴스를 인수로 주든 제대로 동작하는 이유는 Director 클래스가 Builder 클래스의 구체적인 하위 클래스를 모르기 때문이다. 모르기 때문에 교체가 가능하고, 교체되기 때문에 부품으로서의 가치가 높다. 이 교체 가능성을 클래스 설계자는 항상 염두에 둘 필요가 있다. 
• 의존성 주입 - Director 클래스는 Builder 클래스를 알고 있지만 그의 하위 클래스에 대해서는 모르기 때문에 의존하지 않는다고 할 수 있다. 하지만 실제로 동작하기 위해서는 Builder의 구체적인 인스턴스가 필요하다. 다시 말해 Builder의 하위 인스턴스에 의존해서 동작하게 된다. '소스코드에는 쓰여 있지 않지만 실제로는 이 인스턴스를 이용해 동작해 주세요' 라는 의미를 담아 인스턴스를 건네는 방법을 의존성 주입이라고 한다. 클래스 간 결합도를 낮추고 프로그램의 재사용성을 높여주는 기법이다. ex. 전달하는 것은 '필기구'지만 구체적으로 무엇인지는 건네는 시점에 결정할 수 있다.
• 클래스 설계자는 신이 아니기 때문에 미래에 일어날 일을 모두 예상할 수 없다. 그러나 가까운 미래에 일어날 것으로 예상되는 변화에는 견딜 수 있도록 설계해야 한다.
• 기존 소스를 읽고 수정하는 방법 - 추상 클래스만 읽고 있어봐야 결론이 나지 않는다. 적어도 Director 소스를 읽고 클래스의 사용법(메서드 호출 방법)을 이해해야 한다. 그런다음 하위 클래스를 읽고, Builder의 추상 메서드에 어떤 동작이 기대되는지를 알 수 있다.