빌더 패턴(Bilder pattern)

📍빌더 패턴(Bilder pattern)
객체를 정의하고 그 객체를 생성할 때 보통 생성자를 통해 생성하는 것을 생각한다.
하지만 생성자를 통해 객체를 생성하는데 몇 가지 단점이 있어 객체를 생성하는 별도 builder를 두는 방법이 있다. 이를 빌더 패턴이라고 한다.
객체를 생성할 수 있는 빌더를 builder() 함수를 통해 얻고 거기에 셋팅하고자 하는 값을 셋팅하고 마지막에 build()를 통해 빌더를 작동 시켜 객체를 생성한다.

Bag bag = new Bag("name", 1000, "memo");

Bag bag = Bag.builder()
			.name("name")
        	.money(1000)
        	.memo("memo")
        	.build();

📍 빌더를 써야하는 이유
객체를 생성하는 방법이 생성자말고 빌더를 통하는 것이 있다는 것을 알게 되었다.
그렇다면 이미 생성자라는 것이 있는데 빌더 패턴은 왜 생겼고 빌더 패턴을 왜 사용하는 것일까?

1. 생성자 파라미터가 많을 경우 가독성이 좋지 않다.

위에 예시에서 Bag 클래스는 생성자 파라미터를 3개만 받는다. 3개까지는 괜찮다. 하지만 생성자 파라미터로 받아야하는 값이 수업이 많아진다면? 각 값들이 어떤 값을 의미하는지 이해하기 힘들 것이다.

2. 어떤 값을 먼저 설정하던 상관 없다

생성자의 경우는 정해진 파라미터 순서대로 꼭 값을 넣어줘야한다. 순서를 무시하고 값을 넣으면 에러가 발생하거나 엉뚱한데 값이 들어갈 수 있다.
하지만 빌더 패턴은 빌더의 필드 이름으로 값을 설정하기 때문에 순서에 종속적이지 않다. 그냥 쓰이는 곳에서 어떤 필드를 먼저 설정해야하는지 굳이 순서를 생각할 필요 없이 편하게 설정하면 된다.

public Bag(String name, int money, String memo) {
		this.name = name;
    	this.money = money;
    	this.memo = memo;
}

Bag bag = Bag.builder()
		.name("name")
        	.memo("memo")	// memo를 money 대신 먼저!
        	.money(1000)
        	.build();

@Builder

💡 위와 같은 이유로 생성자 대신 빌더를 사용하곤 하는데 그렇다면 빌더는 어떻게 구현해야하나? 우선 코드로 빌더를 만들고 그 안에서 멤버 필드별로 값을 설정하고 빌더를 반환하는 함수를 만들면 된다. 하지만 이 방법은 멤버 필드 별로 함수를 생성해야하는 등 생성자보다 더 번거롭고 해당 클래스에 들어갔을 때 빌더로만 몇십줄을 차지해서 코드 읽기도 불편하다. 그래서 나온 것인 @Builder 어노테이션이다. @Builder는 룸북의 어노테이션으로 이런걸 보면 진짜 룸북 없었으면 어떡하나라는 생각을 들게 만든다. @Builder 어노테이션의 javadoc을 보면 이 어노테이션은 아래와 같이 멤버 필드들에 대해 빌더를 만들어준다. 만일 이 어노테이션이 없었다면 After 부분을 일일이 직접 구현해줘야했다.