Lombok Annotation 관련

lombok이란?

Getter와 Setter를 Annotation형태로 사용하여 Method를 구현하지 않고, 사용할 수 있게 해주는 것
Java Compile 시점에서 특정 Annotation으로 해당 Code를 추가할 수 있는 라이브러리. 가독성과 유지보수에 많은 도움을 주게되나, 잘 못 사용할 가능성이 매우 높은 Library.

 

 

📌 @Data 사용은 NoNo!!

@Data는 아래 Annotation을 한번에 포함하는 강력한 Annotation인 것이에요.

@ToString, @EqualseAndHashCode, @Getter, @Setter, @RequiredArgsConstructor

문제는 @Setter를 포함하고 있다는 것이겠지요?

 

---

 

@Setter

는 그 의도가 분명하지 않고, 객체(인스턴스 변수 값)를 언제든지 변경할 수 있는 것이기 때문에 안전성을 보장받기 힘든 것이에요. 그럴거면 그냥 인스턴스 변수를 private가 아닌 public으로 하는것과 다를것이 없는 것이에요. 만약 회원가입 서비스를 구현할 때, id를 변경되지 않도록 만든다면 id 관련 setter 또한! 제공 되면 안되는 것이에요.
그것은 단순 안점함을 넘어 해당 객체가 자신을 가장 잘 표현하는 구조로 id의 변경 Point를 제공하지 않음으로, id에 변경 기능이 없다는 것을 표현할 수 있는 것이에요.

 

 

@ToString으로 인한 양방향 연관관계 시 순환 참조 문제

 

@Entity
@Table(name = "member")
@Data
public class Member {
    ....
    @OneToMany
    @JoinColumn(name = "member_ship_id")
    private List<MemberShip> ms = new ArrayList<>();
}

@Entity
@Table(name = "memberShip")
@Data
public class MemberShip {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;

    @ManyToOne
    private Member member;

    public Coupon(Member member) {
        this.member = member;
    }
}

만약 Member라는 객체와 MemberShip 객체가 양방향 연관 관계일 때, ToString을 호출하게 되면 무한 순환 참조가 발생하게 되는 것이에요. 이것은 JPA를 사용하다보면 객체를 Json으로 직렬화 하는 가정에서 발생하는 문제와 동일한 것이에요.

 

 

해결 방안은?

@ToString(exclude = "memberShip")
public Class Member {
  ...
}

이렇게 해당 Annotation을 이용하여 ToString 항목에서 제외 시켜 버리는 것이에요.

좋은 방법

---

@NoArgsConstructor 접근 최소화

JPA에서는 Proxy 생성을 위해 기본 생성자는 반드시 하나가 있어야 하는 것이에요.
이 때, 접근 권한이 protected이면 충분합니다! 굳이 외부에 열어둘 필요가 없는 것이지요.

이렇게 하면 장점은 이러합니다.

@Entity
@Table(name = "product")
@Getter
@NoArgsConstructor(access = AccessLevel.PUBLIC) // 테스트를 위해 임시로 Public, 의도한 코드는 PROTECTED
public class Product {

    @Id
    private String id;

    private String name;

    @Builder
    public Product(String name) {
        this.id = UUID.randomUUID().toString();
        this.name = name;
    }
}

위의 코드는 ID생성을 UUID형식으로 하는 것이에요.

ID는 항상 NULL이 아니길 기대하지만, public 생성자를 통해 객체를 생성하게 되면 ID에 NULL이 들어오게 됩니다.
기본 생성자를 아무 이유 없이 열어두는 것은 객체 생성 시 안전성을 떨어트리는 요인이 되는 것이지요.

이럴 때! @NoArgsConstuctor(access = AccessLevel.PUBLIC)을 사용하게 된다면 객체 생성 시 안전성을 어느 정도 보장 받을 수 있는 것이에요!

기본 생성자 접근을 protected로 변경 시 외부에서 해당 생성자를 접근할 수 없기에 아래 코드처럼 생성자를 통해서 객체를 생성해야 하는 것이에요.

@Builder
public Product(String name) {
  this.id = UUID.randomUUID().toString();
  this.name = name;
}

위와 같이 할 경우 UUID생성 코드가 있기 때문에 객체를 생성할 때 반드시 ID값이 들어오는 결과를 보장 받을 수 있는 것이에요.

객체에 대한 생성자를 하나 두고, 그것을 @Builder를 통해 사용하는 것이 효율적일 수 있다!

@Builder(빌더 패턴)란?
복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴.
즉, 객체를 생성할 때, 생성자만을 통해서 생성하는 것은 어려움이 있는 것이에요. 빌더 패턴은 이 문제를 기반으로 고안 된 패턴 중 하나인데, 예를 들면 생성자 인자로 너무 많은 인자가 넘겨지는 경우 어떠한 인자가 어떠한 값을 나타내는지를 확인하기 힘들 수 있죠! 또 어떠한 객체의 경우에는 특정 인자만으로 생성해야 하는 경우가 발생할 때도 있는 것이에요. 이럴 경우 특정 인자에 해당하는 값을 null로 전달해줘야 하는데, 이는 코드의 가독성 측면에서 매우 좋지 않다는 것입니다.

public Studnet(long id, String name, String major, int age, String address) {
  this.id = id;
  this.name = name;
  this.major = major;
  this.age = age;
  this.address = address;
}

위와 같이 학생 객체를 생성하는 코드가 있다고 했을 때, 클라이언트에서는

Student student = new Student(123456, "java", "hihi", 21, "secho");

이런식으로 객체를 생성하게 되는 것이에요. 그런데, 만약 학번과 이름만 아는 경우에는 어떻게 될까요?

Stuent stuent = new Student(123456, "java", null, 0, null);

위와 같이 Garbage Data나, Null값을 넣어 해결하게 되는데, 이럴 경우 특정 파라미터가 어떠한 값을 나타내기 힘들어 지는 것이에요.

만약 Setter를 통해 Java Bean을 생성한다면 어떨까요?

Student student = new Studnet();
student.setId(123456);
student.setName("java");
student.setAge(21);
student.setMajor("hihi");
student.setAddress("secho");

클라이언트에서는 이런식으로 객체를 생성하게 되는데, 함수 호출 1회로 객체를 생성할 수 없기 때문에 객체 일관성이 일시적으로 깨질 수 있는 것이에요. 또한, immutable 객체도 생성할 수 없게 되지요!

점층적 생성자 패턴과 자바 빈 패턴의 장점을 결합한 것이 바로 빌더 패턴이다.

클라이언트 코드에서 필요한 객체를 직접 생성하는 대신, 그 전에 필수 인자들을 전달하여 빌더 객체를 만든 뒤, 빌더 객체에 정의된 설정 Method들을 호출하여 객체를 생성하게 되는 것이에요.

빌더 패턴 사용 시 객체 생성하는데 있어 필수 인자와 선택적 인자를 구별할 수 있게 되고, 선택적 인자의 경우 보다 가독성이 좋은 코드로 인자를 넘길 수 있게 되는 장점이 있는 것이에요. 이러한 장점들을 갖고 있으면서도 객체 일관성을 깨지 않을 수 있습니다.

public interface Buildable<T> {
  T build();
}

일단, interface를 하나 만들어 다른 builder에도 적용하도록 할 수 있는 것이에요.

public class Studnet {
  private long id;
  private String name;
  private String major;
  private int age;
  private String address;

  public Studnet() {

  }

  public static class Builder implements Buildable {
    // 변경 불가 항목
    private final long id;
    private final String name;

    // 변경 가능 항목
    private String major = "";
    private int age = 0;
    private String address = "";

    public Builder major(String major) {
      this.age = age;
      return this;
    }

    public Builder address(String address) {
      this.address = address;
      return this;
    }

    public Student build() {
      return new Student(this);
    }
  }

  private Student(Builder builder) {
    this.id = builder.id;
    this.name = builder.name;
    this.major = builder.major;
    this.age = builder.age;
    this.address = builder.address;
  }
}

Studnet Class안에 Builder라는 정적 Member Class를 하나 만들고, interface를 구현하게 합니다.
최종적으로 build()라는 Method를 통해 객체를 생성할 것인데요. Studnet Class의 인스턴스 변수 id와 name을 필수 인자로 선택하여 final이라는 keyword를 추가하고, Builder를 생성할 때 인자로 넘겨 받게 하였습니다.
그리고 나머지 선택적 인자들은 Builder를 반환하게 하여 Chaining을 통해 인자를 넘겨 받을 수 있도록 하였습니다.

이렇게 되면 클라이언트 코드는 어떻게 될까요?

Student student = new Student.Builder(123456, "java")
                              .major("hihi")
                              .age(21)
                              .address("secho")
                              .build();

이렇게 여러 개의 파라미터를 전달함에도 어떠한 값이 어떠한 의미인지 파악될 수 있고, 필수 인자와 선택 인자도 구별할 수 있게 해주는 것입니다.

다시 본론으로 돌아와서 굳이 ID에 국한 되어 생각하지 않고, 객체 생성 시 반드시 생성되어야 하는 것들에 대한 안전성을 높이는 시각을 갖는 것이 중요하겠지요?

클린코드, 유지보수 하기 좋은 코드들을 이런 사소한 객체 생성부터 생성해보는 것이 좋다고 생각됩니다.

Builder 사용 시 매개변수를 최소화 하자

---

@Builder
pubilc class Member {
  ...
}

Class 위에 @Builder 사용 시 @AllArgsConstuctor Annotation을 붙인 효과가 발생하는 것이에요.
(모든 인스턴스 변수에 대해 매개변수를 받는 생성자 생성)

Member의 ID 생성 전략은 DB의 Auto_Increament를 의존한다고 가정 했을 때, ID를 넘겨 받지 않아야 하는 것이에요. 또, createAt, updateAt 같은 경우 @CreationTimestamp, @UpdateTimestamp 각각 해당 일을 담당하는 Annotation이 있는 것이에요. 이처럼 객체 생성 시 받지 않아야 할 Data들이 Class tkdeks @Builder를 사용하게 되면 문제가 발생하는 것이에요.

public class Member {

  @Builder
  public Member(String email, String name) {
    this.email = email;
    this.name = name;
  }
}

위와 같이 받아야 하는 생성자를 필요 조건에 따라 지정하고, 그 위에 @Builder를 붙이는게 좋겠습니다.

그럼 매개변수 name과 email만 넘겨 받을 수 있게 되는 것이에요.