"응집도를 높이기 위해 Product 객체는 Review 객체를 의존 하지 않는다" 에서 질문이 있습니다.

Question

말씀해주신 부분에서 Product 객체 응집도를 높이기 위해 서로 Review 객체를 모르는 것이 좋다고 말씀 해주셨는데요.   그럼 코드 내용을 보면 Controller 객체에 Product 객체 하고 Review 객체를 알고 있다는 것 인데요. 만약 요구 사항이 Product 데이터 하고 Review 데이터를 가공해서 계산된 데이터를 Client 에게 내려줘야 하는 상황이 있다고 가정 하겠습니다.   그럼 Controller 객체에는 Product 데이터 하고 Review 데이터를 가공해서 계산 하는 비지니스 로직이 분명 있을 것 같습니다.   이것을 Controller 객체에 비지니스 로직이 있으면 Controller 에 대한 역할이 더 분담 되는 것 같아서요.   그래서 제가 생각 한 것은 ProductReview 객체를 만들어서 (어떻게 보면 퍼사드 패턴 이겠네요...) ProductReview 객체가 Product 하고 Review 객체를 알고 Product 하고 Review 객체는 서로 모르는 것이 좋지 않을까 생각 됩니다.   이 방법은 어떻게 생각하시는 궁금 합니다.   굳이 Product 하고 Review 로 대표적으로 설명 해주셨는데 보통 실전에서는 이와 같은 비슷한 상황이 많이 발생 될 것 같습니다.

제미니 · Answer

안녕하세요 리나님 알찬 질문 감사드립니다! 해당 상황에서 적어주신 ProductReviewService 를 만드는 것도 유효한 전략 중 하나입니다 다만, 제 경우 일반적으로 먼저 접근하는 전략 을 말씀드리면 ProductReviewService로 접근하는 것 보다 ReviewService 를 활용하는 전략을 먼저 검토할 것 같습니다 당연히 Review 와 Product 서로 모르는 구조를 유지하는 것이 좋으나 요구사항에 따라 조합에 대한 니즈가 생긴다면 이를 그대로 투영 할 수 있는지 검토하는게 선행 되는게 맞는 것 같습니다 추후에 SellerReviewService, BarndReviewService 이런 식으로 계속 확장 되는 것이 자연스러울 수 있으나 로직이 파편화 되는 문제가 있을 수 있습니다 그래서 현재 상황(어떤 데이터 가공인지는 명확하지 않으나 일반적으로)에서는 일단은 ReviewService 에서 findReviewsForProduct 라던가 적절한 함수로 기능을 제공해보는게 선행되면 좋을 것 같습니다 ( 일단은 현실적인 요구사항을 투영해 작은 방식으로 문제를 해결해보는거죠) 사실 엄밀히 말하면 Review 는 Product 를 완벽히 모르고 있는 것은 아닙니다 (Type, Id 연결 범용화 되어있을 뿐) 반대로 Product는 Review 를 진짜 모르는 상태죠 그렇기 때문에 요구사항에 따라 적절한 기능을 ReviewService에서 먼저 제공해보고 개념적으로도 Review -> Product 가 격벽을 넘어 참조한다고 정의하는 방향도 좋을 것 같습니다 🙂 느낌이 잘 전달됐을지 모르겠네요! 이해안가시는 부분이 있다면 추가 질문 부탁드립니다! 감사합니다! 완강까지 잘 부탁드리고 수강평도 기대하겠습니다!