작성한 질문수 36

1

안녕하세요! 질문 감사드립니다

이 부분은 기존에 ProductSectionService 가 ProductFinder 를 사용하고 있습니다
이걸 말씀해주신 옮긴 후를 보시면 ProductSectionService 가 ProductSectionRepository 만 알게 되는 형태가 됩니다

또한 ProductFinder 도 기존에는 Product, ProductCategory, ProductSection 세 개의 Repository 를 알고 있었는데 이 수정 이후에는 Product, ProductCategory 두 개의 엔티티만 접근하는 형태가 됩니다

해당 강의 10:29 쯤 설명이 나오듯 이 변경 자체로 인해 ProductFinder 는 더 Product 개념 기준의 응집 된 엔티티만 알고있는 형태가 됩니다!

이 관점에서는 ProductSection 은 Product 랑 가깝지 않다 (상세 노출을 위한 메타 정보이므로 라는 논리) 가정을 하고 수정을 해보는 것 입니다!

이런 느낌을 느껴보시려면 수정 후 수정 된 클래스들이 생성자, Import 를 한번 훑어보시면 서로 관계가 어떻게 변했는지 느낌을 느껴보실 수 있을 것입니다!

추가로 궁금하신 것이 있다면 편하게 또 질문 주십쇼!
모쪼록 답이 되었길 바랍니다! 감사합니다! 😃

0

안녕하세요, 인프런 AI 인턴입니다. Cola님!

findSections의 return 부분을 떼어서 ProductSectionService로 옮기는 작업에 대해 궁금하신 점을 이해하였습니다. 이는 소프트웨어 설계와 관련된 중요한 주제인데요, 유사한 상황에서 다양한 접근 방식이 있을 수 있습니다.

1. 응집도와 책임 분리: 기본적으로 함수나 메서드의 위치를 변경하는 작업은 응집도를 높이고 각 클래스나 객체가 자신에게 주어진 책임만을 수행하도록 하기 위한 것입니다. ProductFinder에 많은 책임을 주기보다는, 각 역할이 명확하게 분리되어 있는지를 확인하고, 각 클래스가 특정 역할을 하는 것이 좋습니다.

2. 재사용성과 유연성: 특정 로직을 별도의 서비스로 이동하면, 그 서비스를 다른 곳에서도 재사용할 수 있게 되어 코드의 유연성과 재사용성을 높일 수 있습니다. 이는 궁극적으로 유지보수 비용을 줄이는 데 도움이 됩니다.

3. 코드의 명확성: 메서드의 위치를 변경함으로써, 코드가 보다 직관적으로 읽히고 이해되기 쉽게 합니다. 이는 개발자 간의 커뮤니케이션을 원활하게 하고, 코드를 이해함에 있어서도 큰 도움을 줄 수 있습니다.

이와 관련된 추가 설명을 위해, 기존에 질문하셨던 이들의 답변에서 유사한 상황을 참고할 수 있는 링크를 확인해 보겠습니다:

• “findSections 메서드 위치에 관련하여 질문 드립니다”
  

위 링크에서 보듯이, 코드를 리팩토링하고 책임을 분리함으로써 얻을 수 있는 이점을 담고 있습니다. 특정 메서드의 위치를 변경하는 것은 역할의 명확성과 재사용성, 유지보수를 생각한 결정입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.