Builder Pattern

Tags:

http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-1512.html

자바는 생성자에 값을 넘겨줄때 position 으로만 각 값을 어느 변수에 저장할지 결정할 수 있습니다. 그래서 n개의 변수가 클래스에 존재하는데, 이 각각의 변수에 값을 넘길까 말까의 여부가 사전에 결정되지 않는다면, 그런 모든 경우를 수용하기위해서는 2^n가지 생성자가 필요하죠. 그럼 이를 어떻게 해결하는가.

class Builder {

    private final int DEFAULT_VALUE = -1;
    private int a = DEFAULT_VALUE;
    private int b = DEFAULT_VALUE;
    private int c = DEFAULT_VALUE;

    public Builder a(int v) {
        this.a = v;
        return this;
    }

    public Builder b(int v) {
        this.b = v;
        return this;
    }

    public Builder c(int v) {
        this.c = v;
        return this;
    }

    public Foo build() {
        return new Foo(a, b, c);
    }
}

class Foo {
    private int a;
    private int b;
    private int c;

    public Foo(int a, int b, int c) {
        this.a = a;
        this.b = b;
        this.c = c;
    }

    public String toString() {
        return "a=" + a + ", b=" + b + ", c=" + c;
    }
}

public class BuilderApp {
    public static void main(String[] args) {
        Foo f = new Builder().a(1).c(2).build();
        System.out.println(f.toString());
    }
}

그런데 Builder Pattern은 A, B, C 세가지의 클래스가 있고 이들을 만드는 방법이 각각 다른데 각각을 만드는 인터페이스는 똑같을 때 어떻게 처리하는가의 문제를 다루기 위한 방법을 지칭하는 용어로도 널리 쓰입니다.
(http://www.programmersheaven.com/articles/faisal/pattern.htm)

Comments

2 responses to “Builder Pattern”

  1. 공성식 Avatar
    공성식

    민구님, 안녕하세요? 오랜만에 찾아뵙네요.

    인용하신 자료를 저도 어제 읽었습니다. 물론 자바라는 틀 속에서 본다면 참으로 유용한 패턴이라고 생각합니다. 그런데 Peter Norvig처럼 패턴에 의구심을 품는 사람들의 견해에 따르면 대부분의 패턴이 언어가 가진 한계 때문에 필요한 것이고 뛰어난 언어라면 이런 것들을 언어에서 바로 지원해야 한다고 주장합니다. 상당히 수긍이 가는 얘기죠.

    민구님께서도 루비 해커시니까 느끼셨겠지만, 루비를 하다가 자바를 보면 참으로 답답한 점이 한두가지가 아닙니다. 사실 위의 문제는 (Named parameter + Default value)나 Hash로 해결하면 간단한 건데요. 자바에서도 Hash를 쓸 수 있으니 대충 응용할 수는 있겠지만 static type의 언어와는 별로 맞지 않는 것 같구요. (요즘 C#에서 추구하는 “제 3의 길”인 Type inference가 정적 언어의 문제들을 많이 해결해 줄런지 기대가 됩니다.)

    민구님은 아직도 자바를 많이 좋아하시나요? 전 자바보다는 차라리 자바스크립트로 코딩하는 게 훨씬 편하더라구요.^^

  2. MKSeo Avatar
    MKSeo

    사실 이 코드를 쓰면서 한 생각은 ‘뭐 이딴 언어가…’ 라는 것이었습니다. 갑갑한 것은 사실이죠. 하지만 제게 자바는 생각하는 대로 쉽게 코딩할 수 있는 언어중 하나라서요. 앞으로 제가 어떤 소프트웨어를 개발하는 입장이 되던지 자바를 잘하는 것이 해가 되지는 않을거라 생각합니다. 이제 자바엔 Generics 가 있고, 여기에 Closure까지 추가되면 정말 복잡하고 짜증나는 언어가 될 거라 생각합니다. 그리고 그로 인해 인기가 더 시들해질 수는 있으나, 자바를 할줄아는 인력이나 라이브러리 숫자 등은 줄어들지 않겠죠.

    그래서 자바를 배운다고 하더라도, 문제는 어느정도 수준에 도달하고나면 쓸만한 공부자료를 보기가 정말 어렵다는 것입니다. 프로젝트에 참여하거나 도사들 사이에 끼어보지 않는한 기회가 없잖아요. 그래서 이런 자료는 가뭄의 단비같습니다.

    음, 그리고 말씀하신 해싱을 기반으로 한 방법은 역시나 말씀하신대로 자바를 하는 사람들은 별로 좋아하지 않더군요. 무조건 필드하나씩 만들고 get/set 해야 직성이 풀리는 듯;; 하지만 저라면 해싱으로 해버립니다.

    Type inference라는건 처음듣는데 알려주셔서 감사합니다. 찾아보도록 할께요 ^^

Leave a Reply

Your email address will not be published. Required fields are marked *