이번 강의에서는 이전 강의(16강)에서 도입했던
ForPostRsData 클래스를 제거하고,
다시 RsData 하나로 응답을 통합하는 방향으로 구조를 변경한다.
다만, 그 과정에서
RsData의 data 필드 타입을 Object로 변경하게 되고,
이 선택이 완벽한 해답은 아니라는 점도 함께 짚고 넘어간다.
16강에서는 다음과 같은 상황이 있었다.
RsDataForPostRsDatapublic record ForPostRsData(
String resultCode,
String msg,
PostDto data
) {
}
이 구조는 당장은 동작하지만,
도메인별로 RsData가 계속 늘어나는 문제가 있었다.
👉 응답 클래스 폭증 가능성
그래서 이번 강의에서는
아예 ForPostRsData를 제거하고,
RsData 하나로 모든 응답을 처리하기로 한다.
대신 data의 타입을 Object로 변경한다.
package com.back.global.rsData;
public record RsData(
String resultCode,
String msg,
Object data
) {
}
글 삭제 API는 다음과 같이 변경된다.
@GetMapping("/{id}/delete")
@Transactional
public RsData delete(@PathVariable int id) {
Post post = postService.findById(id).get();
postService.delete(post);
return new RsData(
"200-1",
"%d번 글이 삭제되었습니다.".formatted(id),
new PostDto(post)
);
}
이제:
모두 RsData 하나로 응답 통일이 가능해진다.
강의에서도 분명히 언급된다.
“Object는 최대한 쓰지 않는 게 좋다.”
그 이유는 명확하다.
즉,
Object는 임시방편에 가깝다.
그럼에도 불구하고 이번 강의에서 Object를 선택한 이유는:
👉 지금 구조는 완성형이 아니라 과정 중 하나다.
이번 강의의 핵심은 이것이다.
“Object로 통합하는 건 가능하지만,
좋은 설계는 아니다.”
이 선택 덕분에:
지금까지의 흐름을 정리하면:
public record RsData<T>(
String resultCode,
String msg,
T data
) {
}
Object는 좋은 해결책이 아니다17강은 “이렇게도 되긴 한다”가 아니라
“왜 이렇게 하면 안 되는지”를 이해하게 해주는 강의였다.