Entity 클래스를 만들 떄 

getter/setter를 무작정 생성하는 경우가 있다.

이렇게 되면 해당 클래스의 인스턴스 값들이 언제 어디서 변해야하는지 코드상으로 명확하게 구분할 수가 없어 차후 기능 변경시 복잡해짐

 

따라서 Entity클래스에는 Setter메소드의 사용을 지양하고,

많약 해당 필드의 값 변경이 필요하면 명확히 그 목적과 의도를 나타낼 수 있는 메소드를 추가하는 것이 좋다.

 

예를 들어 주문 취소 메소드를 만든다고 가정해보자

 

잘못된 예

public clsaa Order{
	public void setStatus(boolean status){ //set 메소드 작성 -> 목적과 의도가 명확하지 않다.
    this.status = status;
    }
}

public void 주문서비스의_취소이벤트(){
	order.setStatus(false);  //set메소드를 통해 Order의 필드상태 직접변경
}

올바른 예

public clsaa Order{
	public void cancelOrder(){ //주문취소상태로 만들어주는 메소드 -> 목적과 의도가 명확
    this.status = false;
    }
}

public void 주문서비스의_취소이벤트(){
	order.cancleOrder(); //주문취소 메소드를 통해 변경 
}

그럼 여기서 Setter가 없는 상황에서 어떻게 값을 채워 DB에 삽입해야 할까?

 

기본적인 구조는 생성자를 통해 최종값을 채운 후 DB에 삽입하며, 값 변경이 필요한 경우 해당 이벤트에 맞는 public메소드를 호출하여 변경한다.

 

생성자 대신 @Builder를 통해 제공되는 빌더 클래스를 사용해도 좋다.

(생성자의 경우 채워야 할 필드가 무엇인지 지정할 수 없다는 단점이 있따.)

public Example(String a, String b){
	this.a = a;
    this.b = b;
}

위 생성자에서는 개발자가 new Example(b,a)처럼 a와 b의 위치를 변경해도 코드를 실행하기 전까지는 문제를 찾을 수 없다.

 

 

하지만 빌더를 사용하면 어느 필드에 어떤 값을 채워야 할지 명확하게 인지할 수 있다.

 

Example.builder()
	.a(a)
    .b(b)
    .build();

 

 

한줄요약
1.Entitly에서는 @Setter의 사용을 지양하고 목적과 의도가 명확한 public메서드의 사용을 지향하자
2.Entitly 객체에 값을 채울 때는 Builder 패턴을 사용하면 채워야 할 필드를 명확히 지정할 수 있다.

 

 

참고자료:스프링부트와 AWS로 혼자 구현하는 웹 서비스(이동욱, 2019, p 91)

복사했습니다!