생성자의 인자가 많을 때 빌더 패턴

ATDD 기반으로 개발을 하면서 테스트를 위한 생성자가 게속 발생했다. 물론 규모가 큰 서비스가 아니기 때문에 생성자가 굉장히 많지는 않았지만 

이후 더 큰 서비스를 개발할 경우를 대비해서 생성자의 개수를 제한하는 방법을 공부했다. 

1. 점층적 생성자 패턴

점층적 생성자 패턴은 각 필드의 따른 생성자를 모두 만든다는 것이다. 결국은 객체 생성에 필요한 필드의 수만큼 생성자가 존재하는 것이다.

점층적 생성자 패턴은 잘 동작하지만, 필드의 수가 많아지면 가독성이 떨어지고, 코드 작성에 어려움이 있다는 단점을 가지고 있다.

여기서 말하는 코드 단점은, 필드가 10개인 생성자를 호출할 때, 각각의 위치에 어떤 필드를 넣어야할지 어렵다는 것이다. 

2. 자비빈 패턴

자바빈 패턴은 기본 생성자를 통해 객체를 생성한 후, setter 메소드를 통해 동적으로 필드를 추가하는 방법이다. 자바빈 패턴은 생성자를 통해 유효검사를 시행하지 못한다는 단점을 가지고 있다. 그리고 변경이 불가능한 클래스를 만들 수 없다는 단점을 가지고 있다. public 접근자인 setter 메소드를 통해 계속해서

객체의 값이 변경될 수 있다는 것이다. 

3. 빌더 패턴

점층적 생성자 패턴과 자바빈 패턴을 보완한 것이 빌더 패턴이다. 빌더 패턴의 설명은 실제로 구현한 코드를 보면 쉽게 파악이 될 것이다. 

첫번째 코드는 User 도메인 객체에서 패턴을 이용해서 객체를 생성을 구현한 코드이고, 두번째는 실제 객체 생성을 위해 메소드를 호출한 Fixture 객체이다.

여기서 Fixture 객체는 다른 테스트 코드에서 중복적으로 많이 사용하기 때문에 미리 구현해 놓은 테스트용 객체이다.

     
   public User(UserBuilder userBuilder) {
        super(userBuilder.id);
        this.userId = userBuilder.userId;
        this.password = userBuilder.password;
        this.name = userBuilder.name;
    }

    public static class UserBuilder {
        private Long id;
        private String userId;
        private String password;
        private String name;

        public UserBuilder(String userId, String password, String name) {
            this.userId = userId;
            this.password = password;
            this.name = name;
        }

        public UserBuilder setId(Long id) {
            this.id = id;
            return this;
        }

        public User build() {
            return new User(this);
        }
    }

     
public class UserFixture {
    public static final User DOBY = new User.UserBuilder("doby", "password", "lkhlkh23").setId(3L).build();

    public static final User JAVAJIGI = new User.UserBuilder("javajigi", "password", "자바지기").setId(1L).build();
}

먼저 빌더 패턴을 보자면, UserBuilder 라는 내부 클래스에는 생성자, setter, build() 세 메소드를 하나씩 보자

먼저 생성자는 객체를 생성할 때 항상 필수적으로 사용하는 필드를 매개변수를 갖도록 한다. 물론 기본 생성자를 통해서도 가능하지만, 항상 필수적으로 

사용하는 필드라면 처음부터 생성하면 편하지 않을까? 두번째는 setter 메소드이다. 기존의 setter 메소드와 차이점은 반환값이 this 라는 것이다. 

반환값이 this이기 때문에 chain 형식으로 연속적으로 호출이 가능하다. 그리고 기존의 setter는 객체의 값을 임의로 변경이 가능하지만, 빌더 패턴에서의 

setter는 빌더의 값을 변경하는 것이지 User 도메인 객체를 변경하는 것이 아니기 때문에 문제가 되지 않는다. 그리고 setter 메소드의 이름을 통해 해당 필드를

추론가능하기 때문에 가독성 및 클라이언트 코드 개발에도 효율적이다. 또한, setter 메소드를 통해 유효성 검사도 시행할 수있기 때문에 편리하다.

굉장히 장점이 많다! 그리고 마지막으로 build 메소드를 통해 도메인 객체를 생성한다.

결과적으로 요약하자면,

 (1) 점층적 생성자 패턴 

  - 필드의 수가 많아지면, 생성자의 수도 증가. 필드의 수가 많아지면 생성자의 가독성이 떨어져서 불편하다는 단점

 (2) 자바빈 패턴

  - 기본 생성자에 setter 메소드를 통해 필드를 추가하기 때문에 이후에 객체의 필드를 변경할 수 있기 때문에 객체의 불안정성

 (3) 빌더 패턴

  - 반환값이 this인 setter 메소드를 통해 체인방식으로 가독성이 뛰어난 코드 구현 가능 (또한, 각각의 setter 메소드의 이름을 통해 가독성 증가)

  - 자바빈 패턴의 도메인 객체에 필드를 직접 추가하는 setter 메소드와 달리 빌더 객체의 값을 setter 하기 때문에 도메인 객체의 안전성 확보