기존 프로젝트를 할 땐, 응답을 내 마음대로 막 string했다가, responseDto했다가 boolean했다가 void했다가 난리 엉망진창 부르스 에바쎼바 쌈바 췄었는데....

응답을 통일하는 것의 중요성을 깨달았다!!
(프론트한테 욕 안먹으려면 해야됨요)

그리고 이 과정에서 필요한 개념들까지 함께 알아보자 !

• 제네릭<Generic>
• 빌더 패턴(Builder Pattern)
• Enum을 이용한 코드 관리
• 체이닝(Method Chaining)의 구조

---

🤔 응답 통일 왜해야함?

클라이언트는 API 요청 결과로 JSON을 받는다
백엔드는 큰 상관없지만, 이 결과를 받는 프론트 입장에서 문제가 생긴다
요청을 날리고 받을때마다 매번 JSON 구조가 다르면, 프론트엔드가 이 처리를 경우마다 다르게 처리해주어야하니 빡치게된다..

예를 들어 회원가입 응답이 이런 구조라면:

{
  "code": 200,
  "data": {
    "name": "나",
    "email": "itsmin@naver.com"
  },
  "comment": "회원가입 성공"
}

로그인도, 게시글 조회도, 삭제 응답 등등 모두 이런 구조로 통일하면 모든 응답을 똑같은 방식으로 처리 가능하다! 우리 모두 평화로울 수 있는 조은 방법👍

✅ 일관된 JSON 포맷 응답 → 프론트에서 응답 처리 로직이 단순해진다
✅ 유지보수 용이 → 상태 코드/메시지를 한 곳에서 관리
✅ 테스트 용이 → 응답이 예측 가능하므로 테스트도 단순해짐 (테스트 값 잘못 넣었을 때 바로 알 수 있음)
✅ 확장성 → 새로운 응답 타입 추가도 쉽게 대응 가능!

---

[ 공통 응답 만들기 ]

1️⃣ 응답 코드 관리 : SuccessCode Enum

📌 Enum이란?

Enum은 열거형 상수를 정의할 때 사용하는 Java의 특별한 타입!

🧱 Enum 정의하는 방법

public enum WeekDay {
    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY,
    SUNDAY
}

➡️ WeekDay라는 새로운 타입이 생기고, 7개의 상수(요일)만 들어갈 수 있는 것!!

🛠 Enum 사용법

public class Test {
    public static void main(String[] args) {
        WeekDay today = WeekDay.MONDAY;

        if (today == WeekDay.MONDAY) {
            System.out.println("월요일 에바 ;;");
        }
    }
}

values() 메서드로 모든 enum 값 순회 가능 → enum 안에 존재하는가? 로 활용 가능하다!

for (WeekDay day : WeekDay.values()) {
    System.out.println(day);
}

근데 설명 메시지, 숫자 코드 등 추가 정보를 넣고 싶을 수 있다.
그럴 땐 이렇게 활용해보자

@Getter
@RequiredArgsConstructor
public enum SuccessCode {
    SIGNUP_SUCCESS(HttpStatus.OK, 200, "회원가입 성공"), //값을 정의하기
    LOGIN_SUCCESS(HttpStatus.OK, 200, "로그인 성공"),
    POST_CREATED(HttpStatus.CREATED, 201, "게시글 생성 완료");

    private final HttpStatus httpStatus;  //원하는 값 정의해주고
    private final int code;
    private final String message;
}

활용하면 이렇게 사용 가능하다!

그리고 아래처럼 사용하면~

SuccessCode code = SuccessCode.SIGNUP_SUCCESS;
System.out.println(code.getMessage()); //메세지 가져오기

→ 회원가입 성공 출력!!

👍 Enum 사용 시 장점
1. 코드 중복 줄이기
2. 상태 코드, 메시지 한 곳에서 관리
3. 상태 관리 일관성 유지

---

2️⃣ 공통 응답 클래스 만들기 CommonResponse

아까 만들어둔 Enum 클래스를 사용해서 정형화된 응답을 반환할 수 있는 CommonResponse 클래스를 만들자

🌟 제네릭을 사용하는 이유는?

공통 응답 클래스를 만들 때, 그 안에 들어갈 data는 상황마다 다르다

-회원가입에는 UserResponseDto
-할 일 조회면 TodoResponseDto
-상품 정보면 ProductResponseDto
👉 응답 데이터의 타입이 언제나 다르다!

그래서 이걸 다 Object로 처리하면 매번 형변환을 해야 하고, 타입 안정성이 ↓

➡️ 제네릭(Generic)을 사용하면 하나의 클래스에 다양한 타입의 데이터를 유연하게 담을 수 있다!!

🚧 Builder?

: 객체를 만들 때, 생성자 대신 사용하는 디자인 패턴 중 하나

📌 왜 써야해???
: 필드가 많은 객체를 만들 때, 생성자나 setter로 하면 너무너무 복잡해지니까 깐딴하게 표현하기 위해서!
→ 가독성 & 불변성을 위해서 (객체가 한 번 생성되면 수정할 수 없게)

User user = new User("홍길동", "hong@test.com", "1234");

이런식으로 만들 때, 객체가 몇개 없으면 쓸만하지만,,,
엄청 많아진다면?? 100개를 넣어야한다면?? 가독성이 똥망이 되겠죠?
그럴때 Builder 패턴을 적용하면 된당!!

User user = User.builder()
    .name("홍길동")
    .email("hong@test.com")
    .password("1234")
    .build();

@Builder 이 어노테이션을 클래스에 붙여주면, 이런식으로 바꿔서 사용할 수 있따! 가독성이 좋아졌죵

코드에 적용해보기

@Getter
@Builder
@JsonInclude(JsonInclude.Include.NON_NULL)
public class CommonResponse<T> {
    private final int code;
    private final T data;
    private final String comment;

    public static <T> CommonResponse<T> of(SuccessCode code, T data) {
        return CommonResponse.<T>builder()
                .code(code.getCode())
                .data(data)
                .comment(code.getMessage())
                .build();
    }

    public static <T> CommonResponse<T> of(SuccessCode code) {
        return CommonResponse.<T>builder()
                .code(code.getCode())
                .comment(code.getMessage())
                .build();
    }
}

💡 핵심!!
1. @Builder
: 빌더 패턴 적용 → 필드 순서 상관없이 객체 생성 가능
2. <T> 제네릭 사용
: 어떤 타입이든 data에 넣을 수 있도록! (response마다 다르게 처리 안해줘도 되니까 생산성 향상됨)
3. @JsonInclude.NON_NULL
: null 필드는 JSON에 포함되지 않음 (간결한 응답)

---

3️⃣ Controller에서 사용하기

@PostMapping("/signup")
public ResponseEntity<CommonResponse<UserResponseDto>> signup(@RequestBody SignUpRequestDto request) {
    UserResponseDto userResponseDto = userService.signup(request);
    
    return ResponseEntity
        .status(SuccessCode.SIGNUP_SUCCESS.getHttpStatus()) // 상태 코드 설정
        .body(CommonResponse.of(SuccessCode.SIGNUP_SUCCESS, userResponseDto)); // 응답 본문 설정
}

🧠 왜 이런 구조를 따를까?
ResponseEntity.status(...).body(...)
➡️ 빌더 패턴 기반의 메서드 체이닝 방식

(순서를 바꿔서 body(...).status(...)처럼 쓰면 문법 오류 발생)

따라서 순차적으로 써야함
1. 상태코드 설정
2. 응답 데이터 설정

ResponseEntity.status(...)
: 응답의 HTTP 상태코드 설정 (200, 201, 400, 500 등)
.body(...)
: 응답 본문에 담을 데이터 설정
(CommonResponse.of(...) SuccessCode와 실제 데이터를 기반으로 공통 응답 객체 생성)
➡️ 관심사 분리!

---