왜 이렇게 코드를 작성하였는가?
슬랙 API를 호출하는데 아래와 같이 파라미터의 갯수에 따라 execute함수가 별도로 존재한다.
처음에 이렇게 설계를 한 이유는
슬랙의 경우에는 response의 isOK 필드를 통해서 success, fail을 분리하고 있었고, 그래서 매 요청마다 validateResponse 작업이 필요했다.
그렇다면 매 요청하다 validateResponse를 넣는게 비효율적이라고 생각해서 파라미터의 갯수에 따라서 추상화를 진행했다.
private <T extends SlackApiResponse, K, U, R> T execute(
final SlackTriQuery<T, K, U, R> slackFunction,
final String methodName,
final K param1,
final U param2,
final R param3) {
T result = slackFunction.execute(param1, param2, param3);
validateResponse(methodName, result);
return result;
}
private <T extends SlackApiResponse, K> T execute(
final SlackQuery<T, K> slackFunction, final String methodName, final K request) {
T result = slackFunction.execute(request);
validateResponse(methodName, result);
return result;
}
private String requestToken(String token) {
return String.format("%s %s", BEARER, token);
}
private <T extends SlackApiResponse> void validateResponse(String methodName, T response) {
if (!response.isOk()) {
throw new SlackApiException(methodName, response);
}
}어떻게 개선하고 싶은가?
- 파라미터의 갯수가 달라질 때마다 execute 메서드가 늘어나야 하는가?
- 사실, 각 execute가 호출하는 function과 그에 맞는 매개변수 갯수만 다르다.이 외의 로직은 동일하다. 그렇다면 이를 또 다시 하나로 추상화할 수 있지 않을까?
생각하는 방안
- 가변인자를 사용하자.
하지만, 이펙티브 자바에서 가변인자와 제네릭의 사용은 지양하자고 했다. 가변인자는 결국 배열로 구현이 되는데 배열은 공변, 제네릭은 불공변이기 때문이다.
이어서 작성하겠음 ^^ 궁금하면 계속 보셈 ㅋ
