팩토리 클래스에 객체 생성에 필요한 서비스를 의존을 받았다. 정답일까 아닐까

개요

🗣️  팩토리 메서드는 객체 생성의 책임이 있다고 알고있음.

🗣️ 🗣️ 서비스 클래스에서는 응집도를 위해 유사한 성격을 가진 기능들을 모아야 한다고 알고있음.

 

❓ 이 두가지 생각에 대한 충돌 ❓

---

진행

여기서 드는 의문

Review를 생성하기 위해서는 User Entity 객체와, Product Entity 객체를 받아야 한다.

 

---

상황

클라이언트가 리뷰를 등록하기 위해서는, 리뷰의 내용, 평점을 입력할 것이고.

 

작성완료를 누르면 프런트엔드에서는 해당 리뷰에 대응되는 productId를 넘겨줄 것이다.

 

Case 1.

@Service
@RequiredArgsConstructor
public class ReviewServiceImpl implements ReviewService{
    private final ReviewCrudService reviewCrudService;
    private final ReviewFactory reviewFactory;
    private final UserService userService;
    private final ProductCrudService productCrudService;

    @Override
    public void registerReview(ReviewCreateRequestDto review) {
        reviewCrudService.saveReview(createReviewWithUserAndProduct(review));
    }

    @Override
    public List<ReviewWithAvgProjection> getAllReview(Long productId) {
        return reviewCrudService.getReviewWithRateAvg(productId);
    }

    @Override
    public Review createReviewWithUserAndProduct(ReviewCreateRequestDto review) {
        User user = resolveUser();
        Product product = resolveProduct(review.getProductId());
        return reviewFactory.createWithRegisterRequest(review,user,product);
    }

    private Product resolveProduct(Long productId){
        return productCrudService.getProductById(productId);
    }
    private User resolveUser(){
        return userService.getDummyUser();
    }
}

 

리뷰들을 관리하는 서비스 코드

 

다시 한번

 

리뷰를 등록하기 위해서는 User 그리고 Product객체가 필요하다.

 

그러기 위해 맨 아래 private 클래스로 User와 Product 조회 로직을 만들었다.

 

궁금점, 그리고 고민...

❓ private 메서드는 안 쓰는 게 테스트할 때 여러모로 좋다고(?) 들었습니다.. 그럼 빼야 할까요?

 

❓ 리뷰 관련 서비스인데 다른 엔티티를 여기서 조회를 하는 게 맞을까요?

 

 그래서 ? 난 뭘 했을까 ?

Case 2.

@Service
@RequiredArgsConstructor
public class ReviewServiceImpl implements ReviewService{
    private final ReviewCrudService reviewCrudService;
    private final ReviewFactory reviewFactory;
    private final UserService userService;
    private final ProductCrudService productCrudService;

    @Override
    public void registerReview(ReviewCreateRequestDto review) {
        reviewCrudService.saveReview(createReviewWithUserAndProduct(review));
    }

    @Override
    public List<ReviewWithAvgProjection> getAllReview(Long productId) {
        return reviewCrudService.getReviewWithRateAvg(productId);
    }

    @Override
    public Review createReviewWithUserAndProduct(ReviewCreateRequestDto review) {
        return reviewFactory.createWithRegisterRequest(review);
    }
    
}

 

Case 1. 에서 리뷰를 관리하는 ReviewService에  UserService, ProductService를 의존성 주입받아서 사용했었습니다.

 

Case 2. 에서는 입력받은 리뷰의 내용, 평점, productId 가 담긴 DTO를 그대로 Review를 생성하는 팩토리 메서드로 보내버렸습니다.

 

@Component
@RequiredArgsConstructor
public class ReviewFactory {
    private final UserService userService;
    private final ProductCrudService productCrudService;

    public Review createWithRegisterRequest(ReviewCreateRequestDto reviewCreateRequestDto, User user, Product product){
        String constent = reviewCreateRequestDto.getContent();
        Integer rating = reviewCreateRequestDto.getRating();
        return Review.builder().content(constent).rating(rating).user(user).product(product).build();
    }

    public Review createWithRegisterRequest(ReviewCreateRequestDto reviewCreateRequestDto) {
        User user = userService.getDummyUser();
        Product product = productCrudService.getProductById(reviewCreateRequestDto.getProductId());
        return Review.builder()
                .content(reviewCreateRequestDto.getContent())
                .rating(reviewCreateRequestDto.getRating())
                .user(user)
                .product(product)
                .build();
    }
}

 

요약을 하자면,

 

기존(Case1.) Review 객체를 생성하는 팩토리 메서드에는 (리뷰의 내용, 평점) DTO , Product, User를 인자로 받아 Review 객체 생성.

 

변경(Case1.) Review 객체를 생성하는 팩토리 메서드에는 (리뷰의 내용, 평점, productId) DTO를 인자로 받아 Review 객체 생성.

 

❓ 왜 이렇게 했을까 난?

✅  엔티티 내부에 팩토리 메서드를 안 둔 이유도, 객체 생성 로직이 복잡 해지면 엔티티가 무거워지기 때문에 팩토리 클래스로 분리를 했음.

근데? 팩토리 메서드를 호출하는 호출자에서 객체 생성에 필요한 모든 인자를 넣어 주고 객체 생성을 한다면, 굳이...? 팩토리 메서드를 분리할 필요가 있을까?라는 생각으로 함.

 

✅  팩토리 클래스는 해당 객체 생성에 대한 책임이 있는데, Review객체를 만들기 위해 ReviewService에서 UserService, ProductService를 입력받는 것도 마음에 안 들었다. 예시는 Review만 들었지만 다른 도메인도 비슷한 고충을 겪었다.

 

✅  그래 DTO나 VO는 정적 팩토리 메서드로 생성한다고 하지만, 이거야 말로 객체생성 로직이 복잡한 거 아닌가? 추후 다른 서비스에서 객체를 생성할 일이 있다면 팩토리 메서드에 기본적인 값만 넣어주면 해당 객체와 연관 있는 객체를 알아서 조회해 주니까 편한 거 아녀?

 

❓ 궁금점 총 정리 (궁금한 거 참말로 많다)

❓ 근데 팩토리 클래스에 의존성을 주입해서 쓰는 게 과연 괜찮을까? case 1. 과 case 2. 중 적합한 건?

 

❓ private 메서드를 많이 사용하면 단위 테스트 하기 힘들다고 했는데, 그럼 왜 쓰는 거지?

(Review서비스에서 Product, User 조회하는 로직들은 리뷰서비스랑 직접적인 관계가 없어서 일단 private 메서드로 처리해 놓음)

---

발품 팔기

---

정리

private 메서드에서 사용한 건 단순히 다른 서비스의 기능을 호출한 거밖에 없다. 호출한 서비스에서 단위 테스트가 가능하기에 private로 한다 한들 문제가 크게 없을 거란 생각이 든다. BUT 너무 과하게 시용한다면 코드에 중복이 있을 수도 있을 거 같아서 사용은 하되 떡칠은 하지 말자.

 

아무래도 Case 2. 내가 이상한 생각을 한 거 같다 ㅋㅋㅋㅋㅋ 호출자가 주는 게 맞고, 팩토리 메서드는 객체생성의 책임만 지면 된다.

생성의 책임이라길래 생성에 필요한 것들까지 불러오는 게 하나의 책임이라고 생각했는데 잘못 생각 한걸수도 있겠다!