[DEVLOG] 우당탕탕 제발모발 v2 개발기 - 탈모 진단 API 수정하기 (3) DTO에 따른 응답 생성 클래스 만들기

 

😎 0. 이전 글

[DEVLOG] 우당탕탕 제발모발 v2 개발기 - 탈모 진단 API 수정하기 (1) 변수 작명, Optional, Enum 활용

[DEVLOG] 우당탕탕 제발모발 v2 개발기 - 탈모 진단 API 수정하기 (2) 공통필드가 많은 DTO 만들기

 

 

---

 

🏝 1. 서론

 

지난 번 DTO를 개발하고 나서, 응답을 어떤 식으로 제공하는 것이 좋을 지 생각해봤습니다.

 return ResponseEntity.ok()
	.contentType(MediaType.APPLICATION_JSON)
	.body(JBMBResponseObject.<T>builder()
		.resultCode(...)
		.resultMessage(...)
		.hasError(...)
		.errorMessage(...)
		.errorSource(...)
		.requestURL(...)
		.responseAt(...)
		.responseBody(...)
		.build()
);

응답을 만들어 낼 때마다 위에 있는 코드를 상황에 맞게 계속해서 작성해야 합니다.

그렇기 때문에 '재사용성이 좋고, 다른 개발자도 사용하기 편리한 응답 생성기를 만들어보자' 라는 생각하에 responseCreator를 만들기 시작했습니다.

 

제가 고려한 사항은 다음과 같습니다.

1) 서비스의 한 메소드에서는 보통 한 응답만 나오지 않는다.
: 한 메소드 내에 성공했을 때의 응답, 실패했을 때의 응답, 사용자의 요청이 유효하지 않은 응답, 일부만 성공했을 때의 응답 등, 조건 분기에 따른 다양한 응답이 나올 수 있습니다. 그 때마다 저런 빌더 패턴으로 길게 이어진 응답을 계속해서 작성하는 것은 어렵습니다. 그렇기 때문에 특정 값에 따라 responseCreator가 맞춰서 응답을 보내주면 어떨까? 라는 생각을 했습니다.

2) 서비스의 메소드 마다 '결과 코드'의 정의와 '결과 메시지'가 다르다.
: 따라서 어떤 메소드로부터 들어온 응답인지 구분할 수 있어야 합니다. 그래야 공통적으로 사용할 수 있으니까요.

3) responseBody는 같은 서비스의 메소드로부터 호출되어도 매번 다르다.
: 따라서 responseBody에 들어갈 값은 인자로 전달해야만 합니다.

4) 보내는 응답의 종류는 그렇게 많지 않다.
: 기본적으로 성공한 응답, 성공했지만 구체적인 정보를 추가 전달해야 하는 응답, 일부 성공한 응답, 실패한 응답, 실패했으나 구체적인 정보를 추가 전달해야 하는 응답 등으로 좁힐 수 있었습니다. 

 

---

 

🤔 2. 응답 생성기 만들기 : 어떤 메소드로 들어온 응답인지 구분하기

 

예를 들어 응답기에 successfulResponse를 만들었다고 가정합시다.

그렇다면, 어떤 서비스 레이어의 어떤 메소드에서 해당 successfulResponse를 호출했는지 알 수 있는 방법은 무엇일까요?

이것을 해결하는 것이 급선무였습니다.

 

우선 위의 고려한 사항 3번을 보면, responseBody를 외부에서 만든 후에 successfulResponse의 인자로 던져야 합니다.

이로써 successfulResponse의 인자로는 DTO가 들어오게 됩니다. DTO의 타입은 모두 다르므로, 제네릭으로 함수를 구성합니다.

public static <T> ResponseEntity<JBMBResponseObject<T>> 
	successfulResponse(T responseBody){...}

 

 

 

한 가지 걸리는 것이 있습니다. responseBody를 구분할 수 있는 방법을 찾아야 합니다.

첫 번째 생각한 것은, 들어온 responseBody를 가지고 리플렉션(reflection)을 통해 해당 T 타입의 실제 클래스 이름을 얻어옵니다.

그 후에, 클래스 이름을 기준으로 어떤 메소드로부터 들어왔다는 것을 규정하면 해결할 수 있습니다.

 

String className = responseBody.getClass().getName();
// 메소드와 클래스 이름 리스트를 매핑해놓으면, 어떤 메소드로부터 들어왔는지 확인할 수 있다.

 

그러나 리플렉션(reflection)의 단점이 있습니다. 

getClass를 호출하면 Class 객체를 생성하는 데에 시간을 소모하게 됩니다. 

해당 구문이 많이 불리는 것이 아니라면, 좋은 선택이지만 진단 서비스 레이어로부터 흘러들어온 모든 메소드에서 responseCreator를 호출할 것이고, 그때마다 수도 없이 리플렉션을 사용해 DTO 클래스 이름을 얻어올 것입니다.

 

성능상에 문제가 생길 수 있기 때문에 지양하기로 했습니다.

클래스의 메타 데이터 정보는 JVM의 Perm 영역에 저장됩니다. 만약 Class 클래스를 사용하여 엄청나게 많은 클래스를 동적으로 생성하는 일이 벌어지면 Perm 영역이 더이상 사용할 수 없게 되어 OutOfMemoryError가 발생할 수도 있습니다. 
- 출처 : https://12bme.tistory.com/129

 

두 번째 생각해낸 방법은, 인터페이스를 활용해 DTO에 getIdentifier()라는 각 DTO를 구분할 수 있는 메서드를 만드는 것입니다.

@Data
@Builder
@AllArgsConstructor
public static class ResponseForInitDiagnosis implements DiagnosisResponseDTO {
	private Long diagnosisID;

	@Override
	public JBMBDiagnosisServiceIdentifier getIdentifier() { 
    	return JBMBDiagnosisServiceIdentifier.INIT; 
    }
}

public interface DiagnosisResponseDTO {
	JBMBDiagnosisServiceIdentifier getIdentifier();
}

 

ResponseForInitDiagnosis 클래스는 DiagnosisResponseDTO를 구현하고 있기 때문에 반드시 getIdentifier() 메소드를 완성시켜야 합니다. 

또한 인터페이스를 사용했을 때의 장점은,

/* before */
public static <T> ResponseEntity<JBMBResponseObject<T>> 
	successfulResponse(T responseBody){...}
    
/* after */
public static <T extends DiagnosisDTO.DiagnosisResponseDTO> ResponseEntity<JBMBResponseObject<T>>
	successfulResponse(T responseBody){...}

이렇게 T에 들어올 수 있는 타입을 제한할 수 있습니다. 해당 인터페이스를 상속받고 있는 DTO만 인자로 넣을 수 있다는 것입니다.

이로써 개발자가 다른 도메인의 DTO를 responseBody에 잘못 넣을 일도 없습니다. 바로 컴파일 에러를 발생시키니 말이죠.

 

JBMBDiagnosisServiceIdentifier serviceIdentifier = responseBody.getIdentifier();

이제 어떤 메서드로부터 왔는지 바로 얻을 수 있습니다. getIdentifier의 리턴값을 Enum(JBMBDiagnosisServiceIdentifier)으로 만들어 더욱 편하게 사용할 수 있습니다.

 

---

 

🤔 3. 응답 생성기 만들기 : 메소드와 상황에 따른 응답 매칭하기

 

이제 Enum 값을 통해 어떤 메소드로부터 왔는지 알 수 있습니다.

successfulResponse로 응답을 생성하면, '성공'했을 경우의 값을 리턴해야 합니다.

failedResponse로 응답을 생성하면, '실패'했을 경우의 값을 리턴해야 하죠.

 

 

이 부분을 구현하기 위해서 새로운 Enum을 2개 더 이용했습니다.

이전에 만들었던 JBMBDiagnosisServiceIdentifier는, 서비스를 구분하는 Enum 입니다.

JBMBDiagnosisServiceResultCodeIdentifier는, 서비스의 결과를 구분하는 Enum입니다.

 

그래서 JBMBDiagnosisServiceIdentifier의 인스턴스는 List<JBMBDiagnosisServiceResultCodeIdentifier>를 필드로 가지고 있도록 만들었습니다.

 

아래와 같은 내용은 모두 '진단 초기화'에 해당한다는 것을 Enum으로 표현한 것이죠.

- 진단 초기화 유효하지 않은 요청
- 진단 초기화 성공
- 진단 초기화 성공 + 일부 상태 Shutdown으로 변경
- 진단 초기화 성공 + Shutdown 대상은 있지만 변경 실패
- 진단 초기화 실패

 

 

JBMBDiagnosisServiceResultCodeIdentifier는, JBMBResultCodeLabel을 가집니다.

JBMBResultCodeLabel은, 생성기의 메소드와 매칭되는 것을 표현한 Enum입니다.

 

예를 들어 DTO로부터 'INIT'임을 알아내고 successfulResponse를 호출했다면, INIT에 해당하면서 JBMBResultCodeLabel.SUCCESS를 가지고 있는 INIT_SUCCESS를 얻을 수 있도록 설계했습니다.

 

그 역할을 해내는 메소드는 다음과 같습니다.

public static JBMBDiagnosisServiceResultCodeIdentifier findResultCodeIdentifierByServiceIdentifierAndTypeLabel
(JBMBDiagnosisServiceIdentifier serviceIdentifier, JBMBResultCodeLabel resultCodeLabel) {
        return serviceIdentifier.getResultCodeIdentifierList().stream()
                .filter(resultCodeIdentifier -> resultCodeIdentifier.getResultCodeLabel() == resultCodeLabel)
                .findAny()
                .orElse(JBMBDiagnosisServiceResultCodeIdentifier.NOT_SUPPORTED_TYPE);
    }

 

이제 각 Enum에 맞는 resultCode나, resultCode에 대한 설명, requestURL 등을 필드로 만들어 생성자에서 선언해주면 완성입니다.

 

 

테스트코드를 작성해 의도한 대로 작동하는지 확인했더니 잘 작동하는 것 같습니다.

테스트코드를 추가적으로 작성해 조금 더 검증해야겠지만요.

 

에러 메시지나 error 발생 지점에 관해서는 enum에 고정된 값으로 지정하기 어렵습니다.

이 부분에 대해서는 나중에 개발을 진행한 후에 일지를 적어보도록 하겠습니다.