불변 객체 생성 방법 - 정적 팩토리 메서드와 빌더 패턴

객체 생성 방법에는 여러 가지가 있지만, DTO 같은 불변 객체를 생성할 때는 주로 정적 팩토리 메서드와 빌더 패턴을 많이 쓴다. 

다양한 장단점이 있지만, 불변 객체를 생성한다는 관점에서는
필드가 많고 null일 수도 있는 값이 있으면 빌더 패턴을 사용하고
필드가 적고 모든 필드가 null일 수 없어서 반드시 파라미터로 입력받는다면 정적 팩토리 메소드를
사용하는 것이 적합한 것 같다.

그래서 로그인할 때나 JWT를 refresh할 때 반환하는 DTO의 파라미터가 1, 3개여서 처음 개발할 때는 빌더 패턴을 사용했는데 정적 팩토리 메소드로 리팩토링 했다.

 

빌더 패턴

@Getter
@Builder
public class AuthLoginResponse {

	private MemberResponse memberResponse;
	private String appToken;
	private String refreshToken;
}

@Getter
@Builder
public class AuthRefreshResponse {

	private String appToken;
}

 

정적 팩토리 메소드

@Data
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class AuthLoginResponse {

	private MemberResponse memberResponse;
	private String appToken;
	private String refreshToken;

	public static AuthLoginResponse of(
		MemberResponse memberResponse,
		String appToken,
		String refreshToken
	) {
		return new AuthLoginResponse(memberResponse, appToken, refreshToken);
	}
}

@Data
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class AuthRefreshResponse {

	private String appToken;

	public static AuthRefreshResponse from(String appToken) {
		return new AuthRefreshResponse(appToken);
	}
}

 

PS.빌더 패턴 컨벤션
소셜 로그인시 회원가입이 되어 있지 않으면 password가 null인 상태로 우선 회원가입을 하고 로그인을 하도록 구현했다. 이런 경우 passowrd가 null일 수 있어서 빌더 패턴을 사용했다. 빌더 패턴을 사용시 파라미터가 3개 이상이 된다면, 파라미터를 한 줄씩 써야 더 가독성이 좋다. 그리고 파라미터를 한 줄씩 쓴다면 Git에서 파악이 좀 더 수월하다. 단 마지막 줄에는 ,가 있었다가 없어져서 2줄이 변경사항으로 추적된다. 그래서 Kotlin의 경우 마지막 파라미터에 ,를 허용한다고 한다.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Member extends BaseTimeEntity {

	@Id
	@GeneratedValue
	@Column(name = "member_id")
	private Long id;

	@Column(unique = true)
	private String email;

	private String password;

	private String nickname;

	private String imageUrl;

	@Builder
	public Member(
		String email,
		String password,
		String nickname,
		String imageUrl
	) {
		this.email = email;
		this.password = password;
		this.nickname = nickname;
		this.imageUrl = imageUrl;
	}
}

객체 생성할 때 뿐만아니라 항상 더 적합한 방법을 고민해보고 리팩토링하면서 개발하자.