Setter 사용을 지양하자

Lombok을 사용하여 Getter, Setter로 쉽게 조회, 변경을 할 수 있다.
하지만 Setter 사용을 남발한다면 문제가 발생할 수 있다.
그렇다면 왜 사용하면 안될까?

Setter 사용을 지양해야하는 이유!

• Setter 메소드를 사용하면 값을 변경한 의도를 파악하기 어렵다.

public Member updateMember(long id) {
    final Member member = findById(id);
    member.setFistName("value");
    member.setLastName("value");
    member.setAge("value");
    return member;
}

위 코드는 Member의 정보를 변경하는 코드로 Setter가 나열되어 있지만 이것이 어떤 의도로 데이터를 변경하는지 명확히 알 수가 없다.

• 객체의 일관성을 유지하기 어렵다.

자바 빈 규약을 따르는 Setter는 public으로 언제든지 변경할 수 있는 상태가 된다.
위처럼 회원 변경 메소드뿐만 아니라 모든 곳에서 회원의 이름을 변경할 수 있는 상태가 되기 때문에 객체의 일관성을 유지하기 어렵다.

---

그렇다면 Setter 대신 어떻게 사용해야 할까?

1) 생성자 오버로딩

public class Member {
    private String name;
    private String age;
    
    public Member(String name){
    	this.name = name;
    }
    public Member(String name,int age){
    	this.name = name;
    	this.age = age;
    }

생성자를 오바로딩할 때, 멤버 변수가 많고 다양한 생성자를 가져야 한다면 코드가 길어지고 가독성이 떨어지는 일이 발생한다.
이를 해결하기 위해 Builder 패턴을 사용하자

2) Builder 패턴 사용

public class Member {
    private String name;
    private String age;
    
    @Builder
    public Member(String name, int age){
    	this.name = name;
        this.age = age;
    }

Budiler 패턴은 요구사항에 맞게 필요한 데이터만 사용하여 유연한 클래스 생성이 가능하다.
때문에 다양한 생성자들이 사라지고 전체 생성자 하나만을 가지고 있는 형태로 변경되어 유지보수 및 가독성이 향상된다.
객체를 생성할 때 인자 값의 순서가 상관없다.

3) 정적 팩토리 메소드

public class Member {
    private String name;
    private String age;
    
    public static void createMember(String name, int age){
    	this.name = name;
        this.age = age;
    }
    public static void createMemberName(String name){
    	this.name = name;
    }

정적 팩토리 메소드를 사용한다면 이름을 가질 수 있기 때문에 반환될 데이터를 추측할 수 있다.

참고: https://velog.io/@hope1213/Setter-%EC%82%AC%EC%9A%A9%EC%9D%84-%EC%99%9C-%EC%A7%80%EC%96%91%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C