TIL 55th day

생성 메서드 구현 이유

• 클래스 안에 다양한 연관관계들이 존재할 때, 생성 메서드를 작성하는것이 좋다
• WHY ? "생성하는 지점 변경해야할 시에 생성 메서드만 수정하면 되기 때문"

mapToInt

• Collection의 합을 구하는 방법은 reduce와 sum이 있다.
  • 단, Stream에서 sum()을 사용하려면 IntStream, LongStream, DoubleStream과 같은 기본형(Primitive Type) 특화 스트림을 사용해야한다. 그래서 보통 mapToInt, mapToLong, mapToDouble과 같은 메소드로 스트림을 변환시키고 사용한다.
• 아래는 예시 코드

//Order
        return orderItems.stream()
                .mapToInt(OrderItem::getTotalPrice)
                .sum();
    }

cascade = CascadeType.ALL

• 해당 클래스가 persist 되었을 때, 해당하는 객체도 함께 persist 된다.
  • 아래는 예시 코드

//Order
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    @OneToOne(fetch = LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;

• cacade는 라이프 사이클이 private이면서 범위가 작을 때 사용해야한다. 만약 이곳 저곳에서 호출해서 써야하는 객체라면 cascade를 사용해선 안된다.(연쇄로 저장, 삭제 .. 등으로 인해 예상치 못한 결과가 발생할 수 있기 때문)

JPA protected

• JPA에서 protected 생성자를 만들면 다른 클래스에서 사용할 수 없다.
  • 예로 생성 메소드를 선언해놨는데 누군가 생성 객체를 만드려고 하는 것을 막을 수 있다.
• 또는 @NoArgsConstructor를 선언하는 방법도 있다 아래는 예시

//OrderItem
@NoArgsConstructor(access = AccessLevel.PROTECTED)

JPA 변경 내역 데이터

• query를 사용하는 서비스 클래스 구현은 query를 구현할 수 밖에 없다. 하지만,
  • JPA는 메소드의 변경 내역을 읽어드려서 자동으로 쿼리문을 만들어 DB에 보낸다.

도메인 모델 패턴

비즈니스 로직을 엔티티에 선언해주고 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는(요청하는) 역할을 한다. 반대로, 엔티티에는 비즈니스 로직이 거의 없고, 서비스 계층에 대부분의 비즈니스 로직을 처리하는 것을 트랜잭션 스크립트 패턴이라고 한다. 한 프로젝트 내에서도 두가지 패턴을 다 사용할 수 있다.(로직의 문맥에 맞게 사용하면 됨.)