게시판 프로젝트를 진행하면서 코드의 중복과 Null 처리를 어떻게 해야할 지 고민했다.
게시판의 전체 게시글과 특정 회원이 작성한 게시글을 뿌려주는 Service layer의 로직이 거의 유사했다.
단지 SQL문에 memberId를 where 조건문에 포함시키는 여부만 달랐다.
코드의 중복을 피하기위해서 기존의 전체 게시글을 뿌려주는 메서드에 memberId만 추가해서 구현하기로 결정했었다.
Service 레이어의 메서드는 재사용이 가능해졌지만 한 가지 문제점이 있었다.
바로 null처리였다.
위 메서드를 사용하는 컨트롤러 메서드는 2개다.
문제는 첫 번째 컨트롤러다.
memberId에 null을 건내주고있다는 점인데 저 부분이 상당히 마음에 걸렸다.
memberId에 Null을 주면 전체 게시글을 조회하는 것이고, memberId에 값을 넣어 주면 특정 회원의 게시글들을 조회하는 것인데
이렇게 되면 Null에 의미가 생기게 된다. (findBoards의 파라미터 memberId에 Null은 전체 게시글을 조회하는 것)
우선은 문제점은 유지보수가 어렵고 코드의 가독성이 떨어진다.
직접 코드를 작성한 나는 null의 의미를 단 번에 알 수는 있다. (시간이 지나면 나조차도 모르게될 수 있지만...)
하지만 다른 사람들이 위 null을 보고서는 null의 의미를 해석해야한다.
꽈배기 굴을 만드는 느낌
또 다른 문제점은 어떠한 문제로 특정회원의 게시글들을 뿌려주는 요청에 memberId에 null이 들어오면 예외 처리가 이루어지지않고 전체 게시글 조회가 된다는 점이다.
잘못된 요청에도 정상적인 응답이 내려간다는 것이 가장 큰 문제라고 생각한다.
이 문제는 오버로딩을 통해 더 안전한 방법을 선택하기로했다. (코드의 중복은 감수를 해야했다)
오버로딩을 통해 메서드를 분리하면 null체크도 가능해지니 두 번째 문제도 해결된다.
이게 최선의 해결책이라고는 생각하진 않지만 이렇게 고민해나가는 것이 중요하다고 생각한다.
더 좋은 해결책이 있다면 적용해야겠다.
'Spring' 카테고리의 다른 글
[Spring Security JWT 로그인 (2)] JWT가 탈취된다면 어떻게 대응해야 할까 (0) | 2024.03.10 |
---|---|
Redis Session Clustering [세션 고정] (0) | 2023.12.17 |
S3를 이용한 사용자의 고아 이미지 처리 (1) | 2023.12.02 |
@Query 어노테이션으로 직접 작성한 JPQL은 AUTO Flush 할까? (0) | 2023.07.20 |
Cannot delete or update a parent row: a foreign key constraint fails [CASCADE Option, OrphanRemoval, @Modifying, JPQL 에 대하여] (0) | 2023.07.18 |