setter제거 리팩토링하기
Closed this issue · 5 comments
목적
엔티티의 setter를 제거한다.
체크리스트
- setter 제거하기
- 이에 따른 테스트코드 리팩토링하기
주의 사항
관련 이슈
일정
주요 리팩토링 내용
-
Comment.setArticle()
을 제외하고 모든 setter제거함 -
Comment.setArticle()
은Article.addArticle()
에서만 사용됨.-
public void addComment(Comment comment) { comment.setArticle(this); this.comments.add(comment); }
-
위 코드는 프로덕션 코드에는 전혀 사용되지 않고, 테스트 코드에만 사용됨.
-
테스트코드에만 사용되는데 만든 이유?
- 현재 Article, Comment, Member는 서로가 서로를 필요함(다 단방향으로 만들고싶다...)
- 그래서 일단 Article 인스턴스를 생성하고, 댓글을 add하는 방식으로 테스트용 인스턴스를 구성함
-
-
CommentCreateRequest.toComment()
: 다른 DTO들과의 통일성을 위해 변환 로직 추가 -
필요없는 생성자 제거
- 프로덕션 코드를 위한 생성자는 많아도 된다고 생각하지만 테스트만을 위한 생성자는 만드는 것에 회의적입니다 (단지 제생각)
- 그래서 일단 프로덕션 코드를 위한 생성자만 남겨놓았지만 다른 의견 있으면 말해주세요!!! 논쟁 대환영
써준 글을 보니 양방향 설계때문에 로직이 저렇게 구성될수밖에 없었네요.
보다가 든 한가지 아이디어인데, 만약 Article이 Comment를 가지지 않는다면 어떨까요?
대신 Comment가 필요할 때는 Comment를 직접 요청하고 말이죠.
연관관계는 Comment -> Article 단방향으로 구성하고요.
서비스에서 댓글을 쓰는 디테일페이지 부분은 아예 ArticleId를 가지고 GET /comments로 요청해서 받으면 되고...
Comment 컨트롤러에 GET 로직을 하나 추가하면 되니까요.
이렇게 하면 쪼밀리가 진행했던 comment관련 로직 vuex 모듈화한거랑 방향도 좀 맞을거같고!
사실 전부터 좀 고민이 있었거든요
- 피드에서도 게시글 + 댓글 정보를 싹 받아오는게 부조리해보임
- 댓글 조회 기능이 게시글쪽에 묶여있어, ComemntController나 CommentService의 역할이 모호해짐
- 댓글 조회에 대한 테스트 등이 애매함
연관관계를 재설계하고 댓글 부분을 게시글처럼 독립적인 API로 구성한다면, 이 문제들도 해결될 것 같네요
일단 막 떠오른 아이디어라 슥슥 써보았어요. 글이 많이 난삽하네요.
좀 더 정리가 된다면, 추후 리팩토링 이슈로 진행해 보아도 재미있겠네요.
저도 더 고민해 보겠습니다.
@include42
저도 모든 연관관계를 단방향으로 바꾸는것에 매우매우 좋다 생각합니다ㅎㅎㅎ
사실 처음부터 그렇게 하고 싶었어요 ㅠㅠ
김영한님은
모든 연관관계는 단방향으로만 설계할 수 있다. 단방향으로만 우선 설계하고 필요할 때 양방향을 고려하라.
라고 말씀하시더라구요
저도 단방향 원해요ㅠㅠ
모든 연관관계는 단방향으로만 설계할 수 있다. 단방향으로만 우선 설계하고 필요할 때 양방향을 고려하라.
JPA책에서 그렇게 당부를 하셨는데, 어째서 이렇게 양방향으로 얽히고 설켜있는 것인지..!
Comment를 Article에서 덜어내는 것 찬성이에요.
안 그래도 프론트에서 comment에 vuex 적용하면서 카프카랑 똑같은 생각 했는데요~
feed에서는 feed를 구성하는데 필요한 article 정보만 받아오게 하고,
detail 페이지에서는 article을 다시 fetch하는게 아니라 추가로 필요한 comment관련 정보를 재요청하는 게 좋겠다구요~
엔티티들도 차근차근 리팩토링 해봅시다 🙌
확실히 처음 해보는 JPA 플젝이었던터라...설계 방향을 잘못 잡은 것 같아요.
당시에 저도 코멘트 짜면서, Article에 귀속적이니 GET은 없어도 된다 그러고...좀 복잡하게 짰었죠
그래도 지금 이렇게 생각이 바뀐걸 보면 우리팀이 다들 성장한게 아닐런지ㅎㅎ
조만간 진행해봅시다!! 좀 버겁다 싶으면 페어로 해봐도 될것같구~