<aside> 1️⃣ entity 선언

</aside>

• 엔티티 클래스 안에서 외부에서 주입한 DTO를 인자로 받아 Entity를 생성하는 static 팩토리 메소드를 만드는 방법
  • Entity 클래스에 해당 팩토리 메소드를 추가하면 된다.
• 예를 들어, User Entity에서 **UserDto**를 받아 새로운 User Entity를 생성하는 메소드는 다음과 같이 만들 수 있다.

@Getter
@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    private String name;
    private String email;

    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }

    public static User fromDto(UserDto dto) {
        return new User(dto.getName(), dto.getEmail());
    }

}

<aside> 2️⃣ class를 통한 dto생성방식 설명

</aside>

• DTO 클래스(UserDto) 내부에서 외부에서 주입한 **엔티티(User)**를 인자로 받아서 **UserDto**를 생성하는 static 팩토리 메소드를 만드는 방법
  • UserDto 클래스에 해당 메소드를 추가하면 된다.
• 예를 들어, **UserDto**에서 User Entity를 받아 새로운 **UserDto**를 생성하는 메소드는 다음과 같이 만들 수 있다.

@Data
public class UserDto {

    private final String name;
    private final String email;
		private String address;

		// 생성자를 이용해서 바로 만들어주는 방식
    public static UserDto fromEntity(User user) {
				return new UserDto(
					user.getName(),
					user.getEmail()
				)
    }

		// setter를 이용해서 만들어진 dto 객체에 필요한 값만 세팅해주는 방식
		public static UserDto fromEntity(User user) {
		    UserDto dto = new UserDto();
		    dto.setName(user.getName());
		    dto.setEmail(user.getEmail());
		    return dto;
		}

}

• 위의 예시코드에는 생성자 방식과 @Setter방식 2가지가 있는데 뭐가 더 좋을까?
  • 팩토리 메소드 패턴에는 두 방식 모두 잘 어울린다. 어떤 방식을 선택할지는 상황과 개발자의 선호에 따라 달라진다.
    1. 생성자를 사용하는 방식:
       • 이 방식은 객체 생성과 초기화를 한 번에 처리하므로 코드가 간결해진다. 또한, 생성자의 인자로 필요한 모든 값을 전달해야 하므로 객체가 항상 완전한 상태로 생성된다. 하지만, 생성자의 인자가 많아지면 코드를 이해하거나 수정하기 어려울 수 있다.
    2. setter를 사용하는 방식:
       • 이 방식은 객체 생성과 초기화를 분리하므로 코드가 좀 더 유연해진다. 즉, 필요한 값만 설정하고 나머지 값은 기본값이나 나중에 설정할 수 있다. 하지만, setter를 사용하면 객체가 일시적으로 불완전한 상태에 놓일 수 있으며, 불변 객체를 만들기 어렵다.
  • 따라서, 필요한 값이 많고 객체가 항상 완전한 상태로 생성되어야 하는 경우에는 생성자를 사용하는 방식이 좋을 수 있다. 반면, 필요한 값이 적거나 객체의 상태를 유연하게 변경할 필요가 있는 경우에는 setter를 사용하는 방식이 좋을 수 있다.

<aside> ❓ Setter를 사용하면 왜 불완전한 상태에 놓일 수 있다는 것일까?

</aside>

• 객체를 생성할 때 setter를 사용하면, 객체의 필드를 하나씩 설정해야 한다. 이 과정에서 모든 필드가 아직 설정되지 않은 상태, 즉 일시적으로 불완전한 상태에 놓일 수 있다.
• 예를 들어, 아래와 같이 UserDto 객체를 생성하는 코드를 생각해보자

UserDto dto = new UserDto();
dto.setName("John Doe");

• **setName()**을 호출한 시점에서는 email 필드가 아직 설정되지 않았다. 따라서 이 시점에서 dto 객체는 불완전한 상태에 있다. 이후에 **setEmail()**을 호출하여 email 필드를 설정해야 완전한 상태가 된다.
• 이와 달리 생성자를 사용하면 모든 필드를 한 번에 설정할 수 있으므로, 객체는 항상 완전한 상태로 생성된다. 이는 객체의 불변성을 보장하고, 버그를 줄이는 데 도움이 된다.

UserDto dto = new UserDto("John Doe", "[email protected]");

• 따라서, 가능하다면 생성자나 빌더 패턴 등을 사용하여 객체를 한 번에 완전한 상태로 생성하는 것이 좋다. 하지만, 필요에 따라 setter를 사용하는 것도 유효한 방법이다.

<aside> ❓ 불완전한 상태의 객체가 위험한 이유

</aside>

• 불완전한 상태의 객체는 여러 가지 문제를 일으킬 수 있다.
  1. Null 참조 예외:
     • 객체의 필드가 아직 설정되지 않은 상태에서 그 필드를 사용하려고 하면 null 참조 예외가 발생할 수 있다. 이는 프로그램의 안정성을 해칠 수 있다.
  2. 데이터 무결성 위반:
     • 객체의 필드 중 일부만 설정된 상태에서 데이터베이스에 저장하려고 하면, 데이터 무결성 제약 조건을 위반할 수 있다. 예를 들어, null이 허용되지 않는 필드가 null인 상태로 저장하려고 하면 데이터베이스에서 오류가 발생한다.
  3. 비즈니스 로직 오류:
     • 객체의 상태가 불완전하면, 그 객체에 대한 비즈니스 로직이 잘못 동작할 수 있다. 예를 들어, 객체의 모든 필드를 사용하여 계산을 수행하는 메소드가 있다면, 필드 중 일부가 설정되지 않은 상태에서 그 메소드를 호출하면 잘못된 결과를 얻을 수 있다.