3week_AOS_tech_post_4

레트로핏을 도입하기 전에 이런 궁금증이 생겼다.

어떻게 동작하는 걸까? interface 객체를 만드는 거 같은데 이게 자바에서 가능한가?

Retrofit이란?

• REST API 통신을 위해 구현된 통신 라이브러리.
• AsyncTask 없이 Background Thread에서 실행되면 callback을 통해 Main Thread에서 UI 업데이트를 간단하게 할 수 있도록 제공.
• 다른 통신 라이브러리도 존재하지만 Retrofit의 성능과 구현 방법이 쉽다.

AsyncTask란?

AsyncTask는 Android에서 비동기 작업을 수행하고 그 결과를 메인 스레드에 게시하기 위해 사용되는 유틸리티 클래스입니다. 과거에는 Android 개발에서 백그라운드 작업을 쉽게 수행할 수 있도록 설계된 것이지만, 오늘날에는 Android의 WorkManager, Coroutines, RxJava와 같은 다른 방법들이 더 많이 사용되며, AsyncTask 자체는 deprecated(사용이 권장되지 않는) 상태입니다.

---

사용 방법?

Step1

• @GET, @POST, @DELETE, @UPDATE 어노테이션을 사용하여 인터페이스를 생성

interface TrimApiService {
    @GET("/trims")
    suspend fun getTrimList(): CaArtResponse<List<Trim>>
}

Step2

Retrofit.Builder 만들기

fun getRetrofit(): Retrofit = retrofit ?: Retrofit.Builder()
        .baseUrl(BASE_URL)
        .client(okHttpClient)
        .addConverterFactory(GsonConverterFactory.create())
        .build()

Step3

DTO 클래스 만들기

data class Trim(
    val description: String,
    val exteriorColors: List<TrimItemColor>,
    val interiorColors: List<TrimItemColor>,
    val mainOptions: List<TrimMainItem>,
    val trimImage: String,
    val trimName: String,
    val trimPrice: Long,
    var isChecked: Boolean = false
)

위의 과정을 통해 API Interface의 메서드 객체를 선언하고 동기/비동기로 실행하여 서버에서 Response를 받아온 뒤 작업을 수행

var service: TrimApiService = retrofit.create(TrimApiService::class.java)
service.getTrimList()

// 자바는 인터페이이스를 객체화하는 것을 허용하지 않는데 여기서는 어떻게 만드는걸까?

---

그렇다면 어떻게 API Interface만 구현해서 request를 수행해서 데이터를 받아오는 걸까 ?

우선 retrofit.create() 내부 코드 구현부를 확인해보자

@SuppressWarnings("unchecked") // Single-interface proxy creation guarded by parameter safety.
  public <T> T create(final Class<T> service) {

		// 올바른 인터페이스 타입인지 검사
		// Class 클래스의 내부 함수의 isInterface()를 활용하여 검사
    // Retrofit은 매개변수를 가진 인터페이스를 지원하지 않음 (다음 글 참고)
    validateServiceInterface(service);
    return (T)
       //Proxy 클래스의 메소드를 사용하여 새로운 프록시 인스턴스를 생성
        Proxy.newProxyInstance(
            service.getClassLoader(),

	// 프록시가 구현해야 할 인터페이스 목록을 배열로 제공, 여기서는 service만을 구현하도록 설정되어 있음
            new Class<?>[] {service},
            new InvocationHandler() {
              private final Platform platform = Platform.get();
              private final Object[] emptyArgs = new Object[0];

              @Override
              public @Nullable Object invoke(Object proxy, Method method, @Nullable Object[] args)
                  throws Throwable {
                // If the method is a method from Object then defer to normal invocation.
                if (method.getDeclaringClass() == Object.class) {
                  return method.invoke(this, args);
                }
                args = args != null ? args : emptyArgs;
                return platform.isDefaultMethod(method)
                    ? platform.invokeDefaultMethod(method, service, proxy, args)
                    : loadServiceMethod(method).invoke(args);
              }
            });
  }

우선 코드 부를 이해하기 위해서는 프록시 패턴, 다이나믹 프록시에 대한 이해가 필요하다.

코드 구현부를 보면 다이나믹 프록시사용하고 있다.

프록시 패턴에 대해 간단히 설명하자면

---

프록시 패턴이란?

• 프록시란 "대리인"을 의미합니다.
• 자바에서 프록시는 타겟의 기능을 확장하거나 타깃에 대한 접근을 제어하기 위한 목적으로 사용하는 클래스

예제

1) 기본 인터페이스 및 구현체

• 기본적으로 사용될 인터페이스와 그 구현체입니다.

interface OnlineStore {
    fun purchaseProduct(productName: String): String
    fun refundProduct(productName: String): String
    fun checkInventory(productName: String): Int
}

class ActualStore : OnlineStore {
    override fun purchaseProduct(productName: String) = "$productName purchased!"
    override fun refundProduct(productName: String) = "$productName refunded!"
    override fun checkInventory(productName: String) = 100  // 재고는 100개로 가정
}

2) 프록시 구현체

• 프록시 클래스입니다. 기본 구현체를 사용하되, purchaseProduct() 함수에 로그 기능을 추가해봅시다

class LoggedStore(private val store: OnlineStore) : OnlineStore {
    override fun purchaseProduct(productName: String): String {
        println("Attempting to purchase $productName")
        val result = store.purchaseProduct(productName)
        println("$productName purchase complete.")
        return result
    }

    override fun refundProduct(productName: String) 
				  = store.refundProduct(productName)

    override fun checkInventory(productName: String)
				 = store.checkInventory(productName)
}

4. 장점

• 실제 객체의 코드를 변경하지 않고, 새로운 기능을 추가하거나 수정할 수 있습니다.

5. 활용

프록시 패턴은 타겟의 기능을 확장하거나 타겟에 대한 접근을 제어할 목적으로 사용됩니다.

---

프록시 구현의 문제점

1. 인터페이스를 직접 구현해야한다.

interface OnlineStore {
    fun purchaseProduct(productName: String): String
    fun refundProduct(productName: String): String
    fun checkInventory(productName: String): Int
}

OnlineStore의 구현체에 대한 프록시를 만들려면 OnlineStore라는 인터페이스를 구현해야 한다.

즉, OnlineStore의 모든 메소드를 구현해야 한다.

만약 purchaseProduct() 메소드만 기능을 확장하고 싶다고 하더라도 refundProduct()와 checkInventory()를 모두 override해주어야 한다

override 함수가 하는 일이라곤 타겟의 메소드에 위임하는 것 뿐인데도 말이다.

1. 클래스의 중복이 발생한다.

---

다이나믹 프록시

Java의 Reflection API를 활용하여 프록시 객체를 동적으로 생성할 수 있습니다.

이를 통해 위의 문제점들을 해결할 수 있습니다

자바 공식 문서를 보면 아래와 같다

코틀린 확장 함수 기능으로 코드를 작성해보면

import java.lang.reflect.InvocationHandler
import java.lang.reflect.Method
import java.lang.reflect.Proxy

interface OnlineStore {
    fun purchaseProduct(productName: String): String
    fun refundProduct(productName: String): String
    fun checkInventory(productName: String): Int
}

class ActualStore : OnlineStore {
    override fun purchaseProduct(productName: String) = "$productName purchased!"
    override fun refundProduct(productName: String) = "$productName refunded!"
    override fun checkInventory(productName: String) = 100  
}

class StoreInvocationHandler(private val store: OnlineStore) : InvocationHandler {
    override fun invoke(proxy: Any?, method: Method, args: Array<Any?>): Any? {
        println("Method ${method.name} is being invoked with arguments: ${args.joinToString()}")
        val result = method.invoke(store, *args)
        println("Method ${method.name} invocation completed. Result: $result")
        return result
    }
}

inline fun <reified T> createProxy(store: OnlineStore): T {
    return Proxy.newProxyInstance(
        T::class.java.classLoader,
        arrayOf(T::class.java),
        StoreInvocationHandler(store)
    ) as T
}

fun main() {
    val storeProxy: OnlineStore = createProxy(ActualStore())
    println(storeProxy.purchaseProduct("Shoes"))
    println(storeProxy.checkInventory("Shoes"))
}

다이나믹 프록시의 장점

1. 특정 인터페이스의 메서드를 모두 구현할 필요가 없습니다.
2. 중복 코드를 줄일 수 있습니다.
3. 특정 기능을 확장하고 싶은 경우에만 그 기능에 대한 로직을 InvocationHandler 내부에 구현하면 됩니다.

---

다이나믹 프록시

→ Retrofit은 Java의 Proxy 클래스를 사용하여 인터페이스의 다이나믹 프록시를 생성합니다. → 프록시는 개발자가 호출하는 메소드에 대한 정보 (메소드 이름, 매개변수, 어노테이션 등)를 알 수 있습니다.
→ 이를 통해 Retrofit은 어떤 HTTP 요청을 생성해야 하는지 알아냅니다.

이해가 잘 안가 ..

쉽게 비유를 하자면 레스토랑에서 메뉴를 주문하려고 합니다.

여기서 레스토랑은 Retrofit, 대상은 개발자, 메뉴는 인터페이스(API), 각 메뉴 항목은 API의 메소드입니다.

1. 메뉴 선택 (API 정의): 당신은 음식을 주문하기 전에 메뉴를 확인합니다. 각 메뉴 항목은 특정 음식을 의미하며, 어떻게 만들어야 하는지의 지시사항(어노테이션)이 포함되어 있습니다.
2. 주문 전달 (메소드 호출): 당신은 웨이터에게 메뉴 항목을 지목하며 주문합니다. 여기서 웨이터는 다이나믹 프록시의 역할을 합니다.
3. 웨이터의 역할 (다이나믹 프록시): 웨이터는 당신이 지정한 메뉴 항목(메소드)과 그에 대한 지시사항(어노테이션)을 확인하고 이를 주방에 전달합니다. 주방에서는 이 지시사항에 따라 음식을 준비하게 됩니다.

이 비유에서 웨이터의 주문 처리 방식은 런타임에 이루어집니다. 즉, 웨이터(다이나믹 프록시)는 사전에 어떤 주문이 올지 알 수 없으며, 실제 주문이 들어왔을 때 해당 주문을 처리하는 방법을 동적으로 결정합니다.

Retrofit에서의 적용

개발자가 Retrofit 인터페이스에서 메소드를 호출하면, 실제로 해당 메소드의 구현체는 없습니다

대신, Java의 Proxy 클래스를 사용하여 런타임에 동적으로 생성된 프록시가 호출됩니다.

이 프록시는 메소드의 이름, 매개변수, 그리고 어노테이션 등의 메타데이터를 확인하고 이를 바탕으로 실제 HTTP 요청을 구성합니다.

예를 들어, @GET("users/{user}/repos") 어노테이션이 있는 메소드가 호출되면, 프록시는 GET 요청을 /users/{user}/repos 경로로 생성하게 됩니다.

이와 같은 방식으로, Retrofit은 개발자가 제공한 인터페이스와 어노테이션 정보를 기반으로 네트워킹 하기 위한 프로그램 코드를 자동으로 만들어줍니다.

프록시 객체가 Service 객체를 만들어주고 Service의 함수를 호출하여 Call 객체를 받고 Call 객체에게 일을 시키면 된다.

---

Retrofit은 타입 매개변수를 가진 인터페이스를 지원하지 않는 이유

validateServiceInterface 메소드의 구현 부인데

제공된 인터페이스와 그 상위 인터페이스들이 타입 매개변수(즉, 제네릭)를 가지고 있지 않은지 확인합니다. 실제로 Retrofit은 타입 매개변수가 있는 인터페이스를 지원하지 않습니다.

private void validateServiceInterface(Class<?> service) {
    if (!service.isInterface()) {
      throw new IllegalArgumentException("API declarations must be interfaces.");
    }

    Deque<Class<?>> check = new ArrayDeque<>(1);
    check.add(service);
    while (!check.isEmpty()) {
      Class<?> candidate = check.removeFirst();
      if (candidate.getTypeParameters().length != 0) {
        StringBuilder message =
            new StringBuilder("Type parameters are unsupported on ").append(candidate.getName());
        if (candidate != service) {
          message.append(" which is an interface of ").append(service.getName());
        }
        throw new IllegalArgumentException(message.toString());
      }
      Collections.addAll(check, candidate.getInterfaces());
    }
		
		// 조건문은 서비스 인터페이스에 선언된 모든 메소드를 검사하여 그것들이 유효한지 미리 확인하는 로직
   //  이것은 개발 중에 문제를 조기에 발견할 수 있게 도와줌
  // 여기서는 Java 8의 default 메소드와 정적 메소드를 제외한 나머지 메소드들에 대한 유효성을 검사합니다.
    if (validateEagerly) {
      Platform platform = Platform.get();
      for (Method method : service.getDeclaredMethods()) {
        if (!platform.isDefaultMethod(method) && !Modifier.isStatic(method.getModifiers())) {
          loadServiceMethod(method);
        }
      }
    }
  }

음 코드를 보니 Deque를 사용하네? 어 다시 보니 코드 로직이 BFS네?? 왜 인터페이스 하나만 넘겨주는데 Deque 사이즈를 굳이 1로 초기화해서 인터페이스를 넣어주지?

무슨 이유일까?

BFS (Breadth-First Search, 너비 우선 탐색) 사용 이유

• 인터페이스는 여러 인터페이스를 상속받을 수 있음

• 주어진 인터페이스와 그 인터페이스가 상속받은 모든 인터페이스를 체크하기 위해 BFS 방식이 효율적

  예시: 인터페이스 A가 B와 C를 상속받고, B가 D와 E를 상속받는 경우, A -> B, C 및 B -> D, E 순으로 탐색

**Deque**의 활용

• Deque는 BFS 방식의 탐색을 효과적으로 수행하기 위한 도구로 사용됩니다.

• 코드: Deque<Class<?>> check = new ArrayDeque<>(1);

  이 코드에서 **ArrayDeque**의 초기 크기를 1로 설정하는 것은 최적화의 일부일 수 있습니다. 처음에는 하나의 인터페이스만 있을 것이기 때문에 큐의 크기를 1로 시작하여 필요에 따라 동적으로 확장합니다.

BFS 구현

• 주어진 서비스 인터페이스를 큐에 추가: check.add(service);
• 큐에 아이템이 있으면, 해당 인터페이스를 꺼내어 검사하고, 그 인터페이스가 상속받은 다른 인터페이스들을 다시 큐에 추가: Collections.addAll(check, candidate.getInterfaces());

---

왜 타입 매개변수(제네릭)를 가진 인터페이스를 지원하지 않을까?

Retrofit은 API 선언을 간단하고 명확하게 유지하려고 합니다.

제네릭을 가진 인터페이스를 허용하면 복잡성이 증가하며,

내부적으로 리플렉션을 사용하여 메소드와 어노테이션 정보를 분석하는 과정에서 예상치 못한 문제나 복잡성이 발생할 수 있습니다.

제네릭은 컴파일 시점에 타입의 안정성을 보장하기 위한 것이므로, 런타임에는 제네릭 정보는 대부분 지워집니다. 이것을 타입 소거(Type Erasure)라고 합니다.

따라서 런타임에 제네릭 정보를 정확하게 분석하는 것은 어려울 수 있습니다.

Retrofit은 런타임에 인터페이스와 그 메소드들의 정보를 분석하므로,

제네릭을 가진 인터페이스를 지원하지 않는 이유가 이러한 복잡성을 피하는 한 방법이라고 추측 해 볼 수 있다 🤔

리플렉션 사용하는 예

abstract class ServiceMethod<T> {
  static <T> ServiceMethod<T> parseAnnotations(Retrofit retrofit, Method method) {
    RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);

    Type returnType = method.getGenericReturnType();
    if (Utils.hasUnresolvableType(returnType)) {
      throw methodError(
          method,
          "Method return type must not include a type variable or wildcard: %s",
          returnType);
    }
    if (returnType == void.class) {
      throw methodError(method, "Service methods cannot return void.");
    }

    return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);
  }

  abstract @Nullable T invoke(Object[] args);
}

getGenericReturnType을 사용하여 메서드의 반환 타입을 가져옴

---

어노테이션의 파싱 구현부

RequestFactory.java

private void parseMethodAnnotation(Annotation annotation) {
      if (annotation instanceof DELETE) {
        parseHttpMethodAndPath("DELETE", ((DELETE) annotation).value(), false);
      } else if (annotation instanceof GET) {
        parseHttpMethodAndPath("GET", ((GET) annotation).value(), false);
      } else if (annotation instanceof HEAD) {
        parseHttpMethodAndPath("HEAD", ((HEAD) annotation).value(), false);
      } else if (annotation instanceof PATCH) {
        parseHttpMethodAndPath("PATCH", ((PATCH) annotation).value(), true);
      } else if (annotation instanceof POST) {
        parseHttpMethodAndPath("POST", ((POST) annotation).value(), true);
      } else if (annotation instanceof PUT) {
        parseHttpMethodAndPath("PUT", ((PUT) annotation).value(), true);
      } else if (annotation instanceof OPTIONS) {
        parseHttpMethodAndPath("OPTIONS", ((OPTIONS) annotation).value(), false);
      } else if (annotation instanceof HTTP) {
        HTTP http = (HTTP) annotation;
        parseHttpMethodAndPath(http.method(), http.path(), http.hasBody());
      } else if (annotation instanceof retrofit2.http.Headers) {
        String[] headersToParse = ((retrofit2.http.Headers) annotation).value();
        if (headersToParse.length == 0) {
          throw methodError(method, "@Headers annotation is empty.");
        }
        headers = parseHeaders(headersToParse);
      } else if (annotation instanceof Multipart) {
        if (isFormEncoded) {
          throw methodError(method, "Only one encoding annotation is allowed.");
        }
        isMultipart = true;
      } else if (annotation instanceof FormUrlEncoded) {
        if (isMultipart) {
          throw methodError(method, "Only one encoding annotation is allowed.");
        }
        isFormEncoded = true;
      }
    }

RequestFactory 클래스 내부를 들어가면 Path, Headers 등 파싱하는 구현부를 확인할 수 있다.

조금 더 깊게 확인해보고 싶지만 아직 할게 너무나도 많기 때문에.. 여기까지 알아보자