design

Abstraction 관점에서 보는 프로그래밍 패러다임

/ bahamoth2013 / 댓글 2개

개요

1~3년차 개발자이거나 프로그래밍의 기초가 부족한 사람, 프로그래밍 패러다임이 무엇인지 모르는 사람이라면 이 글을 읽어달라.

코드 재사용이 무엇인지. 특히 객체지향 설계 패러다임에서의 코드 재사용이란 무엇인지 살펴보고자 한다.

 

왜 코드를 재사용하나

코드를 재사용하는 방법은 많다. 흔히들 사용하는 컨트롤CV 패턴이라던지 깃허브다운로드 패턴도 코드를 재사용하는 한 방법이다.

누군가가 만들어둔 코드를 어떤 방식으로든지 재사용하면 그게 바로 코드 재사용이다.

허나 남이 짜둔 코드 블럭을 복사 붙여넣기로 재사용하다 보면 언젠가는 반드시 큰 코를 다치게 된다.

만일 복붙한 코드에 문제가 있어 수정을 해야 한다면? 그런데 해당 코드블럭을 100번 정도 복붙했다면? 너가 이 생이 끝나기 전까지 제대로 수정할 수 있을까?

복붙의 갯수가 늘어날 수록 프로그램의 복잡도는 쓸데없이 높아진다. 코드 재사용에도 바람직한 방법과 그렇지 않은 방법이 있다는거고, 복붙은 그리 좋은 방법이 아니라는 거다.

묻는다. 우리는 왜 코드를 재사용하나? 너는 왜 스택오버플로우에서 검색한 코드를 복붙하여 쓰는거냐?

답은 “귀찮아서” 이다.

나와 같은 문제를 해결하기 위해 고민한 누군가의 결과물을 가져다 쓰기 위함일 수도 있고, 예전에 짜둔 코드가 여기저기서 사용될 필요가 있는데 새로 만들기는 귀찮아서이기도 하다.

과거의 언어 설계자들도 반복되는 작업이 귀찮았다. 다만 복붙보다는 고급진 방법으로 문제를 해결하려 하였다.

 

아래는 어셈블리 Macro 로 문자열을 출력하는 코드를 작성한 예시이다.

Assembly Macro
; A macro with two parameters
; Implements the write system call
   %macro write_string 2
      mov   eax, 4
      mov   ebx, 1
      mov   ecx, %1
      mov   edx, %2
      int   80h
   %endmacro
 
section .text
   global _start            ;must be declared for using gcc
    
_start:                     ;tell linker entry point
   write_string msg1, len1              
   write_string msg2, len2   
   write_string msg3, len3 
    
   mov eax,1                ;system call number (sys_exit)
   int 0x80                 ;call kernel
section .data
msg1 db 'Hello, programmers!',0xA,0xD  
len1 equ $ - msg1          
msg2 db 'Welcome to the world of,', 0xA,0xD
len2 equ $- msg2
msg3 db 'Linux assembly programming! '
len3 equ $- msg3

 

내가 수행하고자 하는 어떤 기능에 이름을 붙이고, 이 기능이 필요할 때 마다 이름을 불러 사용하겠다는 아이디어는

프로그램 언어에 따라 Macro / function / sub-program / sub-routine / method 등등등 여러 가지 형태로 구현되어 불필요한 반복작업을 대체하였다.

프로그램 내에 존재하는 프로그램(이후에는 그냥 function으로 부르도록 하겠다.)으로 반복되는 문제를 해결하기 위한 프로그래밍 사조가 Structured Programming Paradigm이다.

그렇다면, Structured Programming Paradigm은 반복되는 문제들을 일소에 해결하였을까? 아니면 새로운 단계의 복잡한 문제들이 생겨났을까?

 

No Silver Bullet

프레드릭 브룩스 께서 쓴 No Silver Bullet 이라는 에세이를 요약하면 이렇다.

No Silver Bullet

요구사항이 10개인 소프트웨어는 태생적으로 10개 만큼의 복잡한 문제가 존재하고

여기에 개발자 놈들이 싸지르는 문제들이 +α 가 되기 때문에

니들이 아무리 노력해 봐야 +α 만큼의 문제를 줄이는 것 밖에는 안되겠지만 그거라도 해라.

본질적으로 소프트웨어는 복잡하다. 거기에 개발자가 복잡도를 더하지만 않으면 그것만으로도 매우 잘 설계된 소프트웨어다.

function 의 발명은 분명히 반복되는 작업을 줄여주었고, 더욱 크고 복잡한 문제들을 다룰 수 있게 하였다.

허나 문제의 복잡한 수준이 어느 정도를 넘어가면서, 새로운 차원의 문제에 봉착하게 되었다.

 

다음과 같은 요구사항을 만족하는 소프트웨어를 개발한다고 가정해 보자.

문서 편집기 소프트웨어 요구사항

a)로컬 저장소 또는 b) 클라우드 를 통해

1)엑셀 또는 2)워드 또는 3)PPT 문서 파일을 열어서,

a)로컬 저장소 또는 b)클라우드 에 저장하는 소프트웨어

가 있다고 가정해보자.

사용자가 엑셀 파일을 열지, 워드파일을 열지, PPT 파일을 열지는 소프트웨어 실행 중에 결정되기 때문에 아무도 모른다. 그때 그때 달라지는 사용자 맘이다.

또한 사용자가 파일을 로컬 저장소에 저장할지, 클라우드에 저장할지 역시 소프트웨어 실행 중에 결정되기 때문에 마찬가지로 사용자 맘이다.

 

종래의 Structured Programming Paradigm으로 이 문제를 해결하려면

1) 다루고자 하는 시스템의 갯수 x 기능의 갯수 만큼 function을 생성하여

2) 조건에 따라 적절히 분기하여, 해당 시나리오에 맞는 function을 호출

하여야 한다.

 

위의 문제의 경우, system의 갯수는 a)로컬 저장소, b)클라우드 2 개이며

기능의 갯수는 1) 엑셀 열기, 2) 엑셀 닫기, 3) 워드 열기, 4) 워드 닫기, 5) PPT 열기, 6) PPT 닫기 총 6개이다.

따라서, 구현하여야 하는 function의 총 갯수는 2 x 6 = 12 개 이다.

 

예시의 경우 system과 기능의 갯수가 많지 않기 때문에 function의 갯수가 그리 많지 않지만,

현실에서 다루는 문제들은 보통 이것보다 크고 복잡하다. 아무튼 좋다. 까짓거 함 만들어보자.

 

실제로 이 function들을 조건에 맞게 적절히 분기하는 logic을 만든다고 생각해보자.

if (open == 파일저장소) {
    if(source == 엑셀) {
        open엑셀();
    } else if (source == 워드) {
        open워드();
    } else if (source == PPT) {
        openPPT();
    }
} else if (open == 클라우드) {
    ...
}

Structured Programming Paradigm 으로는 분기되는 조건의 갯수만큼 if else 를 발라야 한다.

오케이 좋다. 백번 양보해서 12번 if else 발라가면서 개발해보자.

 

고갱님께서 앞으로는 파일 목록에 에버노트를 추가하고, 에버노트 전용 클라우드에 저장하는 기능을 추가해 달란다.

물론 에버노트 클라우드에는 기존에 존재하던 엑셀 / 워드 / PPT 도 저장이 되어야 한다.

 

c)에버노트 전용 클라우드

7)에버노트 열기 8) 에버노트 닫기

라는 system 과 기능이 추가되었기 때문에 function은 24개를 만들어야 하고 분기로직도 수정을 하여야 한다.

이 시점에서 개발자는 절로 토가 쏠린다. 머리에 피가 쏠리며 대략 정신이 멍해진다.

 

여기서 우리가 줄일 수 없는 태생적인 복잡도는 24개의 function 이다.

허나 24개의 분기처리 로직은 줄일 수 있다.

어떻게?

Object Oriented Paradigm 으로 소프트웨어를 개발하면 된다.

 

Dynamic binding 과 run time 단계에서의 Abstraction

위 프로그램에서 각 경우의 수 만큼 분기처리를 하여야만 했던 이유는 사용자가 어느 시점에 무슨 행동을 할지 몰랐기 때문이다.

사용자가 어느 시점에 뭘할지 모르는 상태, 바로 이 상태를 표현할 수 있는 방법은 없을까?

 

다음과 같은 class 를 살펴보자.

static binding
class File {
    ...
}
 
class 워드File extends File {
    void open() {...};
}
 
워드File foo = new 워드File();
foo.open();

워드File 객체 foo의 메쏘드 foo.open() 은 언제 어느 때 호출하여도 항상 워드File을 open 할 것이다.

다시 말하면, open() 메쏘드의 동작은 컴파일 타임에 이미 결정되었으며, 바뀌지 않을 것이다.

 

그러면 다음과 같은 경우를 살펴보자.

dynamic binding
interface File {
    open();
}
 
class 워드File implements File {
    void open() {...};
}
 
class 엑셀File implements File {
    void open() {...};
}
 
File foo;
if (source == 워드)
    foo = new 워드File;
else if (source == 엑셀)
    foo = new 엑셀File;
 
foo.open();

위와는 다르게, File 인터페이스 객체 foo 의 메쏘드 open() 을 호출하면 실제로 호출되는 method 는 실행 시점의 조건에 따라 그때 그때 달라진다.

source가 워드면 워드File::open() 메쏘드가 호출되고, source가 엑셀이면 엑셀File::open() 메쏘드가 호출된다.

 

아까 전의 문제로 돌아가 보자면, 우리는 사용자가 어느 시점에 뭘할지 몰랐기 때문에 복잡하게 분기처리를 하여야만 했다.

헌데 객체지향 언어에서는 사용자가 뭘 할지 모르는 상태를 위와 같이 추상화할 수 있다.

 

위의 문제에서는 사용자가

1) 클라우드를 사용할지, 로컬저장소를 사용할지 모르고

2) 엑셀을 쓸지, 워드를 쓸지, PPT 를 쓸지 모른다.

 

이 실행 중에 사용자가 뭘 쓸지 모르는 상태를 추상화해보자.

 

Polymorphism, 객체지향 설계의 핵심

이제 개쩌는 매직쇼가 벌어질 시간이다. 최초의 프로그램에선 12가지 조건에 대한 분기 처리를 하여야만 했다.

객체지향의 가장 중요한 특징인 Polymorphism 으로 분기 처리가 어떻게 바뀌는지 살펴보자.

polymorphysm
interface File {
    open();
}
 
interface Cloud {
}
 
interface Local {
}
 
interface CloudFile extends Cloud, File {
    void open();
}
 
interface LocalFile extends Local, File {
    void open();
}
 
class Cloud워드File implements CloudFile {
    void open() {...};
}
 
class Local엑셀File implements LocalFile {
    void open() {...};
}
...
 
File foo;
AbstractFileFactory fooFactory;
if (open == 파일저장소)
    fooFactory = new LocalFileFactory();
else if (open == 클라우드)
    fooFactory = new CloudFileFactory();
    
if (source == 엑셀)
    foo = fooFactory.create(엑셀);
else if (source == 워드)
    foo = fooFileFactory.create(워드);
else if (source == PPT)
    foo = fooFileFactory,create(PPT);
... 
 
foo.open();

조건문에 따른 분기가 5개로 줄었다. 여기서 에버노트 및 에버노트 클라우드가 추가된다면 조건문은 단지 2개가 더 늘어날 뿐이다.

종전에 요구사항이 추가되었을 때 총 24개의 분기처리를 해야만 했던 것에 비하면 다루어야 할 복잡도가 훨씬 간소화되었다.

java8 consumer / supplier 를 이용한 builder pattern 구현

/ bahamoth2013 / 댓글 2개

개요

java8 feature에 대하여 실무에서 활용 가능한 수준으로 best practice 제공

시작하는 말

디자인패턴에 대한 흔한 오해 중 대표적인 한 가지가 “디자인패턴은 프로그램 언어 독립적이다.” 입니다.

허나 실상은 그렇지 않으며, 매우 언어에 종속적이어서 특정 언어에서 제공하는 기능을 면밀히 살피지 않으면

의도한 대로 코드가 동작하지 않을 수도 있고, 해당 언어만의 장점을 살리지 못하는 반쪽짜리 코드가 될 수도 있습니다.

java8 에 추가된 functional interface 중 consumer / supplier 를 이용하면 보다 직관적인 builder pattern을 구현할 수 있습니다.

먼저, 종래에 java에서 builder pattern을 어떻게 구현하는지 살펴보고, 여기에 java8 feature 를 추가하여 어떻게 더 나아지는지 살펴보겠습니다.

builder pattern?

왜 쓰나

디자인패턴을 공부할 때 항상 염두에 두어야 할 것이 있습니다.

이 패턴을 왜 쓰나?

무엇이 좋아지나?

무엇이 안좋아지나?

 

모든 문제를 한방에 해결하는 만능의 해법이란 존재하지 않습니다.

어떤 문제를 해결하기 위한 선택을 하면 반드시 trade-off 가 발생합니다.

 

스타크래프트에서, 미네랄을 먼저 채취하여 후반에 많은 병력을 생산하기 위한 12드론 2해처리 빌드는 초반 러시에 취약하다는 단점이 존재합니다.

반대로 초반에 병력을 상대보다 먼저 뽑는 4드론 빌드는 초반러시에 강력하나 후반으로 갈수록 취약합니다.

초반에 병력도 많이 뽑고, 미네랄도 많이 캐고, 후반 병력도 많이 뽑는 그런 마법과도 같은 해법이 존재할까요?

아니면 그때 그때 상황에 맞는 적절한 젼략을 사용해야 할까요?

 

예시가 즈질스러우니 국민 패턴 싱글톤 패턴을 예로 들어봅시다.

싱글톤으로 생성된 객체는 어플리케이션 실행~종료 시까지 어디에서나 접근 가능합니다.

어플리케이션 내부에서 공유하여야 할 리소스 정보를 쉽게 참조 가능하다는 장점이 존재하지만,

싱글톤 객체는 객체지향 언어 버전의 전역변수나 마찬가지여서

1) 싱글톤 객체 – 다른 객체간 의존성이 높아짐,

2) 인스턴스 생성의 책임이 분리되지 않기 때문에 SRP 위반,

3) unittest객체가 싱글톤 객체에 종속성이 발생하기 때문에 단위 테스트 어려움

등의 단점이 있습니다.

객체지향 5원칙 (aka. S.O.L.I.D)에 만족하는 싱글톤 패턴은 존재하지 않습니다. 싱글톤 자체가 태생적으로 SRP를 위반하기 때문이죠.

허나 파일경로, ip주소 등 1) 쉽게 변경되지 않고, 2) 어플리케이션 영역 전체에 공유가 필요한 리소스는 싱글톤으로 구현하는 편이 유리합니다.

 

GoF 의 디자인패턴에 소개된 모든 패턴은 저마다 장/단점이 분명합니다.

각 패턴의 장/단점이 무엇인지 분명히 알면 장점은 부각시키고 단점은 최소화할 수 있습니다.

장점은 살리고, 단점은 감춘다. 이것이 좋은 소프트웨어 아키텍트가 갖추어야 할 설계 역량입니다.

 

이 글에서 소개할 디자인 패턴은 builder 패턴입니다. 빌더 패턴을 쓰는 이유는 크게 2가지입니다.

1) 귀찮아서

2) 보기 좋으라고

 

다음과 같은 class foo 를 가정해 봅시다.

귀찮은 class 생성
public class foo {
    private String a;
    private String b;
    private String c;
    private String d;
    private String e;
    private String f;
    private String g;
    private String h;
    private String i;
    private String j;
    private String k;
    private String l;
    public foo(String a, String b, String c, String d, String e, String f,
               String g, String h, String i, String j, String k, String l) {
        this.a = a;
        this.b = b;
        this.c = c;
        this.d = d;
        this.e = e;
        this.f = f;
        this.g = g;
        this.h = h;
        this.i = i;
        this.j = j;
        this.k = k;
        this.l = l;
    }
}

new foo(a,b,c,d,e,f…,z) 하기 귀찮습니다. 또 생성자의 parameter 가 길어지면 실수나 오타를 발견하기도 어렵습니다.

 

빌더 패턴은 new foo(a,b,c,d,e,f…,z) 를 new builder().a(a).b(b)…build() 로 보기 좋게 바꾸기 위하여 사용합니다.

‘보기 좋게 바꾼다’고 표현했지만 실제로는 부수적으로 따라오는 몇 가지 장점이 더 있습니다.

1) 실수, 오타의 여지를 줄여줌

2) 생성 parameter에 제약조건을 부여할 수 있습니다. (e.g. 타입, 필수 여부 등등)

 

java8 feature 를 사용하지 않은 builder pattern, Ver. 1

빌더 패턴의 가장 기본적인 아이디어는 객체 생성의 책임을 분리하는 데에 있습니다.

내가 만들려 하는 객체 생성의 역할을 다른 객체에 위임하는 것이죠.

 

builder pattern의 가장 기본적인 구현은 다음과 같습니다.

foo builder
public class fooBuilder {
    private String a;
    private String b;
    ...
    
    public fooBuilder setA(String a) {
        this.a = a;
        return this;
    }
    public fooBuilder setB(String b) {
        this.b = b;
        return this;
    }
    ...
    public foo build() {
        return new foo(this.a, this.b, ...);
}

 

위에서 작성한 fooBuilder class 를 사용하는 방법은 다음과 같습니다.

foo builder
//기존
foo myFoo = new foo(a,b,c,d,...);
 
//builder 사용
fooBuilder myFooBuilder = new fooBuilder();
foo myFoo = myFooBuilder.setA(a).setB(b)....build();

 

위에서 작성한 fooBuilder 클래스는 드닥 마음에 들지 않습니다. foo 객체를 생성하기 위해 불필요하게 fooBuilder 객체도 생성하여야 하니까요.

그러면 fooBuilder 의 메소드를 static으로 만들면 어떨까요? fooBuilder 객체를 생성하지 않아도 foo 객체를 생성할 수 있지 않을까요?

 

java8 feature 를 사용하지 않은 builder pattern, Ver. 2

fooBuilder class를 이렇게 바꿔봅시다.

foo builder
public class fooBuilder2 {
    private String a;
    private String b;
    ...
    
    public static fooBuilder setA(String a) {
        this.a = a;
        return this;
    }
    public static fooBuilder setB(String b) {
        this.b = b;
        return this;
    }
    ...
    public static foo build() {
        return new foo(this.a, this.b, ...);
}
foo builder
//기존
foo myFoo = new foo(a,b,c,d,...);
 
//builder 사용
fooBuilder myFooBuilder = new fooBuilder();
foo myFoo = myFooBuilder.setA(a).setB(b)....build();
 
//builder2 사용
foo myFoo = fooBuilder2.setA(a).setB(b)...build();

불필요한 builder 객체 생성을 없앴습니다. 어떤가요? 잘 작동할까요?

절대 이딴 식으로 프로그래밍 하시면 안됩니다. 오밤중에 서버실 끌려가 밤새도록 디버깅하는 수가 있어요.

fooBuilder2 는 thread safe 하지가 않습니다. 따라서 concurrent 환경에서 foo 객체가 지멋대로 만들어 지는 수가 있어요.

concurrent 와 thread safety 얘기는 길어지니 다음에 따로 다루기로 하고, 암튼 fooBuilder2 는 실패실패 대실패입니다. 절때 이딴식으로 개발하면 안되요.

 

java8 feature 를 사용하지 않은 builder pattern, Ver. 3

서두에 언급하였듯, 디자인패턴은 언어 종속적입니다.

java 언어에서만 지원하는 특별한 feature(inner class) 를 사용하면 builder pattern을 좀 더 아름답게 구현할 수 있어요.

fooBuilder를 foo class 내에 static inner class 로 구현하는 겁니다.

foo builder
public class foo {
    private String a;
    private String b;
    ...
    public foo(String a, String b, String c, String d, String e, String f,
               String g, String h, String i, String j, String k, String l) {
        this.a = a;
        this.b = b;
        ...
    }
    public static class fooBuilder {
        private String a;
        private String b;
        ...
        fooBuilder() {}
        public fooBuilder setA(String a) {
            this.a = a;
            return this;
        }
        public fooBuilder setB(String b) {
            this.b = b;
            return this;
        }
        ...
        public foo build() {
            return new foo(a, b,...);
        }
    }
}
foo builder
//기존
foo myFoo = new foo(a,b,c,d,...);
 
//builder 사용
fooBuilder myFooBuilder = new fooBuilder();
foo myFoo = myFooBuilder.setA(a).setB(b)....build();
 
//builder2 사용
foo myFoo = fooBuilder2.setA(a).setB(b)...build();
 
//static inner class builder 사용
foo myFoo = new foo.fooBuilder.setA(a).setB(b)...build();

static inner class 로 객체 생성 코드를 보기 좋게 바꾸었지만 여전히 단점은 존재합니다.

1개의 foo 객체 생성을 위하여 반드시 1개의 fooBuilder 객체를 생성해야 하는 문제는 남아 있습니다.

메모리를 효율적으로 사용해야 하는 환경에서는 적합하지 않습니다.

또한 builder class가 inner class 로 포함되면서 클래스 재사용성에 대한 고민을 다시 해야 합니다.

 

java8 feature 를 사용한 builder pattern

지금까지

1) GoF가 처음 제안한, 고전적 형태의 Builder pattern

2) java의 언어적 특징, static inner class 를 사용한 Builder pattern

을 살펴 보았습니다.

이번에는 java8에 추가된 functional interface 를 사용하여 builder pattern을 구현하는 방법을 소개할건데요.

시작하기에 앞서, java8의 Consumer / Supplier 가 무엇인지 알아보도록 합시다.

 

functional interface?

functional interface에 대하여 잘 모르는 분들이 많이 계시리라 생각되어 간단히 소개합니다.

함수형 언어의 가장 큰 특징 중 하나가 function(=method) 을 변수처럼 사용하는겁니다.

 

예를 들면,

var foo = someFunction(); //함수 definition에 대한 reference
 
var foo = (x) -> x*x; //definition이 없는 함수(=익명함수)에 대한 reference

 

예제에서의 var foo 처럼 function을 저장하는 방법이 언어적으로 제공되어야 하는데요.

java8 이전의 java에서 L-value 에 위치할 수 있는 type 들(Object나 primitive type 등)은 function reference 에 대한 저장을 고려하지 않았습니다.

때문에 함수형 언어로의 확장을 위하여 java8은

1) var foo 와 같은 역할을 제공하는 새로운 type을 정의하던가

2) 아니면 기존에 제공하던 언어 기반을 크게 변경하지 않으면서 꼼수를 쓰던가

둘 중 하나를 선택하여야 했습니다.

 

java8 은 2) 를 선택하는 꼼수를 두었는데요. 그 꼼수가 functional interface 입니다.

java compiler는 @FunctionalInterface 라는 Annotation 이 포함된 다음 조건을 충족하는 interface를 위 예제의 var foo 처럼 취급하기로 약속하였습니다.

1) non-static method

2) non-default method

3) only 1 method in interface

@FunctionalInterface
interface var {
    void execute(String arg);
}
 
var foo = (x) -> System.out.println(x);
 
foo.execute("Hello");

참 쉽죠?

 

java8에선 기본적인 형태의 functional interface 를 미리 정의해 두었습니다.

Consumer / Supplier / Function / Predicate 4가지인데요.

각각 용도가 다릅니다만 자세한 것은 다음 기회에 다루도록 하겠습니다.

 

Consumer 를 사용한 builder pattern

기본적인 아이디어는 이렇습니다.

1) 생성하고자 하는 객체의 setter method 를 변수로 저장

2) 객체 생성 시 저장해 두었던 setter method를 실행하여 객체 생성

 

구현체는 다음과 같습니다.

foo builder
public class foo {
    private String a;
    private String b;
    ...
    public foo(String a, String b, String c, String d, String e, String f,
               String g, String h, String i, String j, String k, String l) {
        this.a = a;
        this.b = b;
        ...
    }
    public static class fooBuilder {
        private foo _myFoo;
        private List<Consumer<foo>> _setters = new ArrayList<>();
        public <T> fooBuilder with(BiConsumer<foo, T> setter, T val) {
          if (_myFoo == null)
               _myFoo = new foo();
         Consumer<foo> c = _myFoo -> setter.accept(_myFoo, val);
         _setters.add(c);
         return this;
       }
       public foo build() {
           foo val = _myFoo;
           _setters.forEach(_setters -> _setters.accept(val));
           _setters.clear();
           return _myFoo;
       }
    }
}
foo builder
//function interface 로 구현한 builder class 사용
foo myFoo = new foo.fooBuilder().with(foo::setA, "A").with(foo::setB, "B")...build();

 

위 패턴의 장단점을 살펴 볼까요?

장점은

1) 코드 재사용 : 생성할 Class 에 존재하는 setter 를 Builder Class에 중복으로 생성하지 않고 변수에 담아 재사용

 

단점은

1) 대동소이한 Builder를 매번 재구현하여야 함

 

Supplier / Consumer 를 사용한 builder pattern

위의 단점을 개선하여 봅시다.

Builder 코드를 재사용하여 생산성을 높이는 데에는 다음 두 가지 방법이 있습니다.

1) 상속을 통한 재사용

2) Generic을 통한 재사용

 

여기선 2) 방법으로 builder pattern을 고쳐 보겠습니다.

 

구현체는 다음과 같습니다.

generic builder
public class GenericBuilder<T> {
    private final Supplier<T> _instance;
    private List<Consumer<T>> _setters = new ArrayList<>();
    private GenericBuilder(Supplier<T> instance) {
        this._instance = instance;
    }
    public static <T> GenericBuilder<T> of(Supplier<T> instance) {
        return new GenericBuilder<T>(instance);
    }
    public <U> GenericBuilder<T> with(BiConsumer<T, U> consumer, U value) {
        Consumer<T> c = setter -> consumer.accept(setter, value);
        _setters.add(c);
        return this;
    }
    public T build() {
        T value = _instance.get();
        _setters.forEach(iter -> iter.accept(value));
        _setters.clear();
        return value;
    }
}
foo builder
//Generic builder class 사용
foo myFoo4 = GenericBuilder.of(foo::new)
        .with(foo::setA, "A")
        .with(foo::setB, "B")
        .with(foo::setC, "C")
        ...
        .build();

 

위 패턴의 장단점은 다음과 같습니다.

장점은

1) 코드 재사용 : GenericBuilder 클래스를 범용적으로 재사용 가능

 

단점은

1) inner class 를 사용할 때 보다 직관적이지 않다.

 

결론

여기서는 builder 패턴만 다루었지만 다른 패턴 공부도 위와 비슷하게 진행하시면 많은 도움이 될 겁니다.

이 패턴을 왜 쓰는지

내가 사용하는 언어에 특화된 구현 방법은 없는지

특히 java8 feature 를 사용할 여지가 있는지