티스토리 뷰

최근 개인 토이프로젝트를 진행하다 보면,

사실상 코드를 짜다 모르는 부분은 어딘가에서 검색한 결과를 붙여넣어 수정하면 굴러간다는 사실을 개발공부 근 1년만에 알아차렸다.

 

지금에서 시간을 잡아먹는 부분은 이 메서드가 어디있어야 할까. 이놈이 저기에서 동작하는게 과연 맞는가. 하는 문제로 허무하게 시간을 보낼때가 있다.

 

게시판을 만들며 댓글구현은 금방하는 일이겠거니 하며 진행하다가 뜬금없는 고민에 빠져 책(클린코드)을 구매하고

객체지향의 원칙까지 다시한번 주의깊게 본 경험이 생겨 올려본다.


댓글
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ReplyDTO {

    /**
     * 댓글 pk
     */
    private Long replyNo;

    /**
     * 댓글 내용
     */
    @Min(value = 3)
    private String replyContent;

    /**
     * 게시글 번호 fk
     */
    private Long boardNo;

    /**
     * 댓글 생성일자
     */
    private String replyRegDate;
}

참으로 특별한거 없는 댓글 DTO이다.

    <!-- 댓글 조회 -->
    <select id="getReply" resultType="ReplyDTO">
        SELECT
            r.reply_content,
            r.reply_reg_date

        FROM
            reply r

        WHERE
            board_no = #{boardNo}

        ORDER BY
            reply_reg_date DESC;
    </select>
    
@Mapper
public interface ReplyRepository {

    /**
     * 댓글 조회
     * @param boardNo
     * @return
     */
    List<ReplyDTO> getReply(Long boardNo);
}

게시판 번호를 통해 댓글리스트를 반환하는 과정이 담긴 xml파일과 ReplyRepository이고 고민은 여기서 시작된다.

 


내가 만든 List<ReplyDTO>는 과연 어디로 가야하나?

평소대로의 생각이라면

boardService가 있다는 가정하에

//BoardDTO
public class BoardDTO {

    /**
     * pk 게시글
     */
    private Long boardNo;

    /**
     * 게시글 제목
     */
    private String boardTitle;

    /**
     * 게시글 내용
     */
    private String boardContent;

    /**
     * 게시글 작성자
     */
    private String boardWriter;
    
    /**
     * 댓글 리스트
     */
    private List<ReplyDTO> replyList;

}


//BoardService

    /**
     * 자유 게시판 특정게시글 조회
     * @param boardNo
     * @return
     */
    public BoardDTO getFreeViewArticle(Long boardNo) {
    
        //게시글 가져옴
        BoardDTO dto = freeRepository.getFreeViewArticle(boardNo);
        //댓글리스트
        List<ReplyDTO> replyList = replyRepository.getReply(boardNo);
        
        dto.setReplyList(replyList);
       
        return dto;
    }

(게시판의 특정게시글을 조회하는 getFreeViewArticle 메서드가 있다)

아마 평소와 같은 방식으로 만들었다면 이런 과정이 되었을 것이다.

상세조회를 했을시 게시글안에 댓글리스트를 집어넣어 반환된다면 아마

[{
    boardTitle: 제목,
    boardWriter: Mo-Greene,
    boardContent: 내용,
    replyList : {
                    replyContent: 댓글내용,
                    replyRegDate: 댓글생성날짜
                }
}]

이런 객체를 보내게 될것이다.

 

뭐 나쁘지 않다. 이게 맞는 방법일 수도 있다고 생각하지만 혹여나 하는 생각을 하게 되었다.

만약 댓글의 요청사항이 바뀐다면?

여러가지가 있을 수 있다고 본다. 게시판이 늘면서 댓글리스트를 다른곳에서도 사용한다던가?

replyRegDate를 포맷팅하여 보낼 수도 있고(프론트의 영역이라고 생각하지만)

쉽게 생각은 안나지만 어떤 기상천외한 요구가 생길지는 아무도 모른다.

 

그럴때마다 댓글의 구현을 "getFreeViewArticle"이란 메서드 안에서 실행한다면

이 메서드는 더 이상 게시글 상세조회의 역할이 아닌 그 이상의 역할을 하게 된다는 생각을 하게되었다.

 

단일 책임 원칙 (SRP: Single Responsibility Principle)
하나의 클래스에는 하나의 책임을 가진다.

getFreeViewArticle는 게시글을 가져오는 책임과 댓글을 가져오는 2개의 책임을 갖게 되었다.

만약 이 메서드를 수정하는 상황이 온다면 List<ReplyDTO> 에서 어떤 에러가 나올지 매번 생각하며 코드를 짜야한다.


그래서 결론은?
BoardController
    /**
     * 자유게시판 특정게시글 조회
     * @param boardNo
     * @param model
     * @return
     */
    @GetMapping("/free/{boardNo}")
    public String getFreeView(@PathVariable Long boardNo, Model model) {

        BoardDTO dto = boardService.getFreeViewArticle(boardNo);
        List<ReplyDTO> replyDtoList = replyService.getReply(boardNo);

        model.addAttribute("dto", dto);
        model.addAttribute("replyDto", replyDtoList);
        return "board/free/freeView";
    }

 

간단히 분리해서 model에 각각의 값으로 보내주었다.

만약에 boardService에서 요구사항이 생겨 고친다면 저부분만 고치면 될것이고

replyService의 요구사항이 생기면 그 부분만 고치면 다른것을 건드릴 필요없이 해결이 될 것이다.

Comments