[박서영] 7주차 과제 제출#26
Conversation
RockScissors
left a comment
There was a problem hiding this comment.
이번 과제도 수고하셨습니다!
이전 주차에 피드백 드렸던 내용들은 이번 리뷰에서는 생략하였습니다 🙂🙂
| private Long id; | ||
|
|
||
| @ManyToOne (fetch = FetchType.LAZY) | ||
| @JoinColumn(name="post_id", nullable = false) |
There was a problem hiding this comment.
PostLike는 생성 후 어떤 Post에 대한 좋아요인지, 어떤 Member가 누른 건지 바뀌면 안 되는 데이터이므로 updatable = false 설정을 추가적으로 넣어도 좋을 것 같습니다~
| } | ||
|
|
||
| @PostMapping("/{id}/like") | ||
| public ResponseEntity<String> likeComment (@PathVariable("id") Long postId, |
There was a problem hiding this comment.
현재 메서드 이름이 like/unlikeComment로 작성되어 있습니다! 도메인인 post에 맞추어 변경해주세요~
| COMMENT_NOT_FOUND(404, "해당 id의 댓글이 존재하지 않습니다."), | ||
| COMMENT_ACCOUNT_MISMATCH(401, "댓글의 주인이 아닙니다"), | ||
| LIKE_ALREADY_EXISTS(400, "좋아요가 이미 존재합니다."), | ||
| LIKE_NOT_FOUND(404, "좋아요가 존재하지 않습니다."); |
There was a problem hiding this comment.
댓글 좋아요 관련해 구현하신 코드들을 유지하실 생각이라면, CommentLike / PostLike 에 대한 에러 코드를 분리하는 것을 권장드립니다.
현재 LIKE_ALREADY_EXISTS, LIKE_NOT_FOUND 두 에러 코드를 CommentLike 와 PostLike 가 같이 사용하고 있는데요, 이 경우 서버 로그에 에러가 찍혔을 때 어느 리소스의 문제인지 추적이 어렵고, 추후 각 에러의 상태 코드나 메시지를 다르게 다루고 싶어도 공유되고 있기에 변경이 어렵다는 문제가 있습니다.
// 이렇게 분리
POST_LIKE_ALREADY_EXISTS
POST_LIKE_NOT_FOUND
COMMENT_LIKE_ALREADY_EXISTS
COMMENT_LIKE_NOT_FOUND
| public static PostCommentResponse of (Long postId, List<Comment> commentList) { | ||
| return PostCommentResponse.builder() | ||
| .postId(postId) | ||
| .postCommentList(commentList.stream().map(CommentResponse::of).collect(Collectors.toList())) |
There was a problem hiding this comment.
Java 16 이상에서는 collect(Collectors.toList()) 대신 toList() 를 바로 사용할 수 있어서, stream().toList()를 사용하면 코드가 조금 더 간결해질 것 같습니다!
commentList.stream().map(CommentResponse::of).toList()
| @Getter | ||
| @Builder | ||
| @AllArgsConstructor(access = AccessLevel.PRIVATE) | ||
| public class MemberCommentResponse { |
There was a problem hiding this comment.
현재 클래스와 같은 단순 조회용 응답 DTO는 상태 변경이 없고, 단순 데이터 전달 역할이며, 생성 로직도 정적 팩토리로 충분하다는 점에서 class가 아닌 record 타입을 사용하는 것을 권장드립니다!
record는 Java에서 제공하는 데이터 전용 타입으로,
모든 필드를 기반으로 생성자, getter, equals, hashCode, toString이 자동 생성되어 보일러플레이트 코드를 줄여줍니다.
또한 “데이터를 담는 객체”라는 의미가 구조적으로 드러난다는 장점이 있습니다.
public record MemberCommentResponse(
String memberNickname,
List<CommentResponse> memberCommentList,
Long count
) {
public static MemberCommentResponse of(Member member, List<Comment> commentList) {
return new MemberCommentResponse(
member.getNickname(),
commentList.stream()
.map(CommentResponse::of)
.toList(),
(long) commentList.size()
);
}
}
| @@ -0,0 +1,34 @@ | |||
| package efub.assignment.community.post.controller; | |||
There was a problem hiding this comment.
현재 구조에서 PostCommentController와 관련 DTO가 post 패키지 안에 위치하고 있는데, 실제로는 Comment 도메인을 다루고 있고 내부에서도 CommentService를 호출하고 있어 구조적으로 댓글 리소스에 더 가까워 보입니다.
구조적 일관성 측면에서 comment 패키지로 이동시키는 편이 더 자연스럽고, 추후 유지보수 측면에서도 더 명확할 것 같습니다.
(+ MemberComment~ 역시 마찬가지입니다!)
| //[댓글 생성] | ||
| @PostMapping | ||
| public ResponseEntity<Void> createComment(@PathVariable("postId") Long postId, | ||
| @RequestBody CommentRequest request) { |
There was a problem hiding this comment.
@Valid 로 입력 값을 검증해주시면 더 좋을 것 같습니다!
📌 구현 기능
🗂️ 과제 정리
댓글 삭제
게시글 좋아요 생성
게시글 좋아요 삭제