[05] 리팩토링 - 2

이전글

[05] 리팩토링 - 1

코드리뷰

1. 메서드 반환 타입을 Void로 변경
2. 메서드 구현시 Setter -> Builder 활용
3. ErrorCode Message 활용
4. UserRole을 변경 Method 변수명 변경
5. PostReadResponse에 of() 메서드 생성

리팩토링

UserRole을 변경하는 Method 변수명 변경

이전 코드(UserController)

    @PostMapping("/{userId}/role/change")
    public Response<UserSwithResponse> switchToAdmin(@PathVariable Integer userId, Authentication authentication){
        log.info("toAdmin userId ={}", userId);
        UserSwithResponse user = userService.toAdmin(userId, authentication.getName());
        return Response.success(user);
    }

변경된 코드

    @PostMapping("/{userId}/role/change")
    public Response<UserSwithResponse> changeUserRoleToAdmin(@PathVariable Integer userId, Authentication authentication){
        log.info("toAdmin userId ={}", userId);
        UserSwithResponse user = userService.changeUserRoleToAdmin(userId, authentication.getName());
        return Response.success(user);
    }

• switchToAdmin() -> changeUserRoleToAdmin()
• toAdmin() -> changeUserRoleToAdmin()
  유저의 역할을 관리자로 바꾸는 것이므로 메서드 명만 보고 어떤 역할을 하는 메서드인지 알 수 있도록 수정하였다.

+ UserRole을 변경할 때 Setter가 아닌 Builder 사용

이전 코드(UserEntity)

public class User extends BaseUserEntity {
    ...

    public void setUserRole(UserRole userRole) {
        this.userRole = userRole;
    }
}

변경된 코드(UserEntity)

public class User extends BaseUserEntity {
    ...
    public User changeUserRole(UserRole userRole) {
        return User.builder()
                .id(this.id)
                .password(this.password)
                .userRole(userRole)
                .userName(this.userName)
                .build();
    }
}

기존에 존재하던 Set 메서드를 삭제하고 Builder를 생성해서 Return 하였다.

이전 코드(UserService)

    public UserSwithResponse toAdmin(Integer userId, String name) {
        ...
        user.setUserRole(UserRole.ADMIN);
        user.setLastModifiedAt(LocalDateTime.now());
        userRepository.save(user);
        return new UserSwithResponse(user.getUserName(), user.getUserRole());
    }

변경된 코드(UserService)

    public UserSwithResponse changeUserRoleToAdmin(Integer userId, String name) {
        ...
        userRepository.save(user.changeUserRole(ADMIN));
        return new UserSwithResponse(user.getUserName(), user.getUserRole());
    }

이전 코드에서는 Role과 ModifiedAt을 Set을 사용하여 수정하였으나, Builder와 @@LastModifiedDate를 사용하여 Set을 모두 없애버렸다. changeUserRole() 메서드는 User엔티티를 반환하므로 save의 매개변수에 바로 대입하였다.

PostReadResponse에 of() 메서드 생성

Service 로직에서 Builder를 사용하여 반환하는 것보다, DTO단에서 Builder를 사용하는 것이 코드의 가독성과 활용성을 늘릴 수 있지 않을까 생각했다.
로직으로 가득 찬 Service 클래스에 Builder 패턴으로 인해 많은 줄이 생기는 것을 방지할 수 있고, 메서드화가 되어있다면 재사용을 하기 편리하기 때문이다.

of() 메서드 생성(PostReadResponse)

public class PostReadResponse {
    ....
    public static PostReadResponse of(Post post) {
        return PostReadResponse.builder()
                .id(post.getId())
                .title(post.getTitle())
                .body(post.getBody())
                .userName(post.getUser().getUserName())
                .createdAt(post.getCreatedAt())
                .lastModifiedAt(post.getLastModifiedAt())
                .build();
    }

}

이전 코드(PostService)

    public PostReadResponse getPost(Integer postId) {
        ...
        return PostReadResponse.builder()
                .id(readPost.getId())
                .title(readPost.getTitle())
                .body(readPost.getBody())
                .userName(readPost.getUser().getUserName())
                .createdAt(readPost.getCreatedAt())
                .lastModifiedAt(readPost.getLastModifiedAt())
                .build();
    }

변경된 코드(PostService)

    public PostReadResponse getPost(Integer postId) {
        Post readPost = postRepository.findById(postId)
                .orElseThrow(
                        () -> new SNSAppException(POST_NOT_FOUND, "해당 페이지가 없습니다.")
                );

        return PostReadResponse.of(readPost);
    }

of() 메서드를 사용하면서 서비스 단의 전체 코드의 가독성을 증가시킬 수 있었다.