[JAVA / Design Pattern] 생성자 인자가 많을 때는 Builder 패턴을 적용해보자

-
정적 팩터리나 생성자는 같은 문제를 갖고 있다.

선택적 인자가 많은 상황에 잘 적응하지 못한다는 것이다.

포장 판매되는 음식에 붙어있는 영양 성분표를 나타내는 클래스로 예를 들어보면,

이 성분표에 반드시 포함되어야 하는 항목은 몇 가지 되지 않는다.

총 제공량(serving size), 1회 제공량(servings per container),  1회 제공량당 칼로리(calories per servings) 등이 그런 항목이다.

그러나 선택적인 항목은 무려 20개가 넘는다.  총 지방 함량(total fat), 포화 지방 함량(saturated fat),

트랜스 지방 함량(trans fat)  콜레스테롤 함량(cholesterol) 등이 그런 항목이다.

보통 프로그래머들은 이런 상황에 점층적 생성자 패턴을 적용한다.

필수 인자만 받는 생성자를 하나 정의하고, 선택적 인자를 하나 받는 생성자를 추가하고,

거기에 두 개의 선택적 인자를 받는 생성자를 추가하는 식으로, 생성자들을 쌓아 올리듯 추가하는 것이다.

결국 모든 선택적 인자를 다 받는 생성자를 추가하면 정의는 끝나게 된다.

첫번 째 방법은 점층적 생성자 패턴이다.

실제코드가 어떻게 작성되는지 살펴보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public class NutritionFacts {
    private final int servingSize; //필수 인자 
    private final int servings; //필수 인자
    
    private final int calories; //선택 인자
    private final int fat; // 선택 인자 
    private final int sodium; //선택 인자 
    private final int carbohydrate; //선택 인자
    
    
    public NutritionFacts(int servingSize, int servings) {
        this(servings,servings,0);
    }
    
    public NutritionFacts(int servingSize, int servings,int calories) {
        this(servings,servings,calories,0);
    }
    public NutritionFacts(int servingSize, int servings,int calories,int fat) {
        this(servings,servings,calories,fat,0);
    }
    public NutritionFacts(int servingSize, int servings,int calories,int fat, int sodium) {
        this(servings,servings,calories,fat,sodium,0);
    }
    
    public NutritionFacts(int servingSize, int servings,int calories,int fat,int sodium,int carbohydrate) {
        
        this.servingSize = servingSize;
        this.servings = servings;
        this.calories = calories;
        this.fat = fat;
        this.sodium = sodium;
        this.carbohydrate = carbohydrate;
    }
        
}
cs

이 클래스로 객체를 생성할 때는 설정하려는 인자 개수에 맞는 생성자를 골라 호출하면 된다.

1
NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 3, 35, 27);
cs
그런데 이렇게 하다 보면, 설정할 필요가 없는 필드에도 인자를 전달해야 하는 경우가 생긴다.

위에 코드에서 생성자호출 하는 this 부분 마지막에 0을 적어준것이 그런 사례다.

인자가 6개라서 그다지 흉해 보이지는 않겠지만, 인자 수가 늘어나면 엄청 더러워진다.





두번째의 방법은 getter setter 주는 형식으로 setter를 만들어 필드의 값을 채워주는 

자바빈(JavaBeans) 패턴이다.

자바빈 패턴은 작성해야 코드의 양은 조금 많아질 수 있겠지만, 객체를 생성하기도 쉬우며

읽기도 좋다.

하지만 심각한 단점이 있는데, 1회의 함수 호출로 객체 생성을 끝낼 수 없으므로,

객체 일관성(consistency)이 일시적으로 깨질 수 있다는 것이다.

이 말은 객체를 생성해준 후 setter 작업으로 필드멤버를 변경해주는 작업이 더 들어가기

때문이다. 일관성이 깨진 객체를 사용할 때 생기는 문제는 실제 버그 위치에서 한참 떨어진

곳에서 발생하므로 디버깅 하기도 어렵다.

또한 자바빈 패턴으로 변경 불가능(immutable)클래스를 만들 수 없다는 것이다.

setter 작업으로 인해 필드멤버의 값을 변경 할 수 있어서 그렇다.





점층적 생성자 패턴의 안전성에 자바빈 패턴의 가독성을 결합한 것이 바로 빌더(Builder) 

패턴이다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
public class NutritionFacts {
    private final int servingSize; //필수 인자 
    private final int servings; //필수 인자
    
    private final int calories; //선택 인자
    private final int fat; // 선택 인자 
    private final int sodium; //선택 인자 
    private final int carbohydrate; //선택 인
    
    public static class Builder {
        //필수 인자
        private final int servingSize;
        private final int servings;
        
        //선택적 인자 - 기본값으로 초기
        private int calories = 0;
        private int fat =0;
        private int carbohydrate = 0;
        private int sodium = 0;
        
        public Builder(int servingSize, int servings) {
            // TODO Auto-generated constructor stub
            this.servingSize = servingSize;
            this.servings = servings;
        }
        
        public Builder calories(int val) {
            calories = val;
            return this;
        }
        
        public Builder fat(int val) {
            fat = val;
            return this;
        }
        
        public Builder carbohydrate(int val) {
            carbohydrate = val;
            return this;
        }
        
        public Builder sodium(int val) {
            sodium = val;
            return this;
        }
        
        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
        
    }
    private NutritionFacts(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;        
    }
}
cs


1
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 5).fat(5).calories(500).build();
cs
이렇게 사용한다.

calories 부터 sodium 함수는 자기자신을 리턴하므로 계속해서 .함수이름(값) 만

호출함으로써 멤버를 초기화 해줄수 있다.

이 코드는 작성하기도 쉽고, 그리고 무엇보다 읽기 쉽다.

생성자와 마찬가지로, 빌더 패턴을 사용하면 인자에 불변식(invariant)을 적용할 수 있다.

build 메서드 안에서 해당 불변식이 위반되었는지 검사할 수 있는 것이다.

빌더 객체에서 실제 객체로 인자가 복사된 다음에 불변식들을 검사 할 수 있다는 것,

그리고 그 불변식을 빌더 객체의 필드가 아니라 실제 객체의 필드를 두고 검사할 수 있다는 

것 은 중요하다.

불변식을 위반한 경우, build 메서드는 IllegilStateException을 던져야 한다.

이 예외 객체를 살펴보면 어떤 불변식을 위반 했는지도 알아낼 수 있어야 한다.

요약하자면, 빌더 패턴은 인자가 많은 생성자나 정적 팩터리가 필요한 클래스를 설계할 때,

특히 대부분의 인자가 선택적 인자인 상황에 유용하다.

클라이언트 코드 가독성은 전통적인 점층적 생성자 패턴을 따를 때보다 훨씬 좋아질 것이며,

그 결과물은 자바빈을 사용할 때보다 훨씬 안전할 것이다.






스택오버플로우에 DTO에 빌더 패턴을 사용해야되는지 의견을 나누는 글이 있다.

https://stackoverflow.com/questions/31818287/should-i-use-builder-pattern-in-dto






댓글

댓글 쓰기

이 블로그의 인기 게시물

Filter url 제외시키기

-
Filter 제외시키기 Spring Filter url 제외시키기 필터를 등록할때는 모든 url을 필터 처리하기위해 아래와 같이 필터를 맵핑하는 경우가 많다. < filter > < filter-name > SessionFilter </ filter-name > < filter-class > com.todo.restful.filter.SessionFilter </ filter-class > </ filter > < filter-mapping > < filter-name > SessionFilter </ filter-name > < url-pattern > /* </ url-pattern > </ filter-mapping > 하지만 몇개를 제외하고 싶다면 어떻게 해야 할까? x String path = (( HttpServletRequest ) req ). getRequestURI (); if ( path . contains ( "/login" )) { // 제외한 url이 들어 왔을때 동작할 코드 작성 } else { // 원래의 필터 기능 동작을 할 코드 작성   } 현재의 url을 가져와서 비교를 하는 방법을 사용하면된다. 하지만 위에 코드는 오류를 범할 가능성이 높은 코드다. 왜냐하면 contains() 함수를 사용했기 때문에 login이 포함되면 필터링 동작을 안하기 때문이다. 그러므로 p
자세한 내용 보기

[Spring,Java] Validator 구현하기

-
이미지
validation 스프링에서 유효성 검사하기 (Spring Validator) 개요 스프링 프레임워크 4.0은 빈 검증기 1.0(JSR-303) 와 1.1(JSR-349)를 지원하며 Spring의 Validator 인터페이스에 적용할 수 있습니다. 어플리케이션은 빈 검증기를 전체에 사용할것인지, 아니면 부분적으로만 사용할것인지 선택할 수 있습니다. 검증 로직의 어노테이션 사용 없이 DataBinder 를 이용하여 Validator 를 추가적으로 등록할 수 있습니다. DataBinder 은 애플리케이션의 도메인모델에 동적으로 바인딩 할 때 유용합니다. 스프링은 데이터바인딩을 하기 위해 DataBinder 을 제공해줍니다. Validator 와 DataBinder 는 MVC 프레임워크에서 주로사용되는 유효성 검사 패키지 입니다. 스프링 MVC에서 Validator 인터페이스는 HTML 폼에 있는 모든필드를 검증하기 위해서 사용됩니다. controller 클래스안에 @InitBinder 어노테이션을 이용해서 설정할 수 있습니다. @InitBinder 어노테이션은 메소드레벨의 어노테이션이며, WebDataBinder 를 초기화하기 위해 사용합니다. WebDataBinder 클래스는 웹에서 온 request 파라미터들을 model 오브젝트에 바인드를 해줍니다. 자신이 만든 커스텀 Validator 를 컨트롤러에 등록하고 싶다면 WebDataBinder.addValidators() 메소드를 통해 등록이 가능합니다. 인자나, model 오브젝트에 @Validator 어노테이션을 작성하면, 핸들러 메소드가 이를 알고 커스텀 validator를 등록해줍니다. 만약 검증을 위반하는 사항이 발견된다면, 자동적으로 에러가 BindingResult 에게 가게 됩니다. 들어가며 검증기를 사용하는 방법은 두가지가 있습니다. 첫째로 모델 오브젝트에 주석을 사용해서 작성하는 방법과, 두번째로 Validator
자세한 내용 보기

[Spring] Mock framework에 대하여

-
이미지
Mock에 대하여 Mock Framework   목(Mock)이 무엇이고 왜 필요하죠? 우리가 Junit 으로 테스트를 할때에는 보통 어떤 시스템에 입력을 주었을 때 기대하는 출력이 나오는지를 주로 검증하게 됩니다. 단위 테스트에서는 보통 입력 값을 테스트 대상 오브젝트의 메소드의 파라미터로 전달하고 메소드의 리턴 값을 출력 값을 보고 검증합니다 다음과 같이 말이죠! public class TestEx { ​ //평범하게 파라미터로 들어온 값을 반환하는 함수입니다. public int printInteger ( int i ) { return i ; } @Test public void IntegerTest () { // 5가 출력이 되었는지 단위테스트를 해준다. assertThat ( printInteger ( 5 ), is ( 5 )); } } ​   하지만 이렇게 단순히 리턴 값 출력을 하는것이 아니라 테스트 오브젝트가 간접적으로 의존 오브젝트 (써드파티 라이브러리 등 내가 만들지 않고 다른사람이 만든 API) 가 그 행위가 제대로 이루어 졌는지 검증하고싶다면 어떻게 할까요? 아래와 같이 검증합니다!       이런 경우에는 테스트 대상의 간접적인 출력 결과를 검증해야하고, 테스트 대상 오브젝트와 의존 오브젝트 사이에서 일어나는 일을 검증할 수 있도록 특별히 설계된 목 오브젝트(Mock Object) 라는 것이 있습니다. 목 오브젝트 는 테스트 오브젝트가 정상적으로 실행되도록 도와주면서 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는데 활용할 수 있게 해줍니다. 데이터베이스, 웹서버, 웹애플리케이션서버 ,FTP 서버 등 환경 구축을 위한 작업시간이 필요한 경우에 사용합니다. 특정 모듈을 갖고 있지 않아서 테스트 환경을 구축하지 못하거나 다른 사람과 협의나 정책이 필요한 경
자세한 내용 보기