我试图在 Retrofit
上创建一个包装器来抽象我的服务实现。到目前为止,我已经让编译器成功编译:
package com.example.spark.testapp.services;
import com.example.spark.testapp.services.apis.Get;
import com.example.spark.testapp.services.apis.Post;
import com.example.spark.testapp.services.utils.*;
import com.example.spark.testapp.services.utils.Error;
import java.util.List;
import retrofit2.Call;
import retrofit2.Callback;
import retrofit2.Response;
import retrofit2.Retrofit;
public class ServiceLayer {
public <T> void performGet(String url, final Class<Get<T>> clazz, com.example.spark.testapp.services.utils.Callback<T> callback) {
Retrofit retrofit = new Retrofit.Builder().baseUrl("").build();
Get<T> service = retrofit.create(clazz);
//Pass authentication token here
Call<T> t = service.get(url, "");
executeCallback(callback,t);
}
public <T> void performPost(String url, final Class<Post<T>> clazz,com.example.spark.testapp.services.utils.Callback<T> callback) {
Retrofit retrofit = new Retrofit.Builder().baseUrl("").build();
Post<T> service = retrofit.create(clazz);
//Pass authentication token here
Call<T> t = service.post(url, "");
executeCallback(callback,t);
}
public <T> void executeCallback( final com.example.spark.testapp.services.utils.Callback<T> callback , Call<T> call) {
call.enqueue(new Callback<T>() {
@Override
public void onResponse(Call<T> call, Response<T> response) {
callback.onSuccess(response.body());
}
@Override
public void onFailure(Call<T> call, Throwable t) {
///Find out what exactly went wrong. Populate Error. and then...
com.example.spark.testapp.services.utils.Error e = new Error();
callback.onFailure(e);
}
});
}
}
编译时,问题出在调用方法时:
private void getString() {
ServiceLayer s = new ServiceLayer();
s.performGet("",Get<String>.class,this); //Cannot select from parameterised type
}
我用 Google 搜索了一下,发现由于类型删除,这是不可能的。美好的。
但我的问题是,编译器不应该在这里报错吗?在这条线上? :
public <T> void performGet(String url, final Class<Get<T>> clazz, com.example.spark.testapp.services.utils.Callback<T> callback)
我的服务层是如何编译的?
编辑
这个问题似乎被误解了。我不是在寻找一种方法来让这个设计发挥作用。我理解其中的缺陷,并且我们找到了一种更好的分层服务方式。问题是关于语言本身的有趣/奇怪的行为。
最佳答案
But my question is, shouldn't the compiler raise an error here?
方法签名在 Java 中是完全正确的。泛型方法签名受与普通方法相同的规则控制。
在泛型方法中,您可以在代码中执行的操作取决于参数类型。例如,如果您有此方法:
public static <T> void test(List<T> list, Class<T> clazz)
throws InstantiationException, IllegalAccessException
{
list.add(clazz.newInstance());
}
它可以编译,但是如果我们添加下一行:
list.add(new Integer(1));
不会因为在编译时list
只接受 T
的实例.因此泛型方法定义明确。
当您尝试调用泛型方法时,编译器无法推断 T
从参数。主要问题显然是 Class<Get<T>>
构造,在方法签名中有效但不推荐。虽然,你可以做一个不安全和奇怪的转换来使方法调用编译和工作:
s.performGet("",(Class<Get<String>>)(Class) Get.class,this);
执行此转换链,编译器现在可以推断出 T
,因为泛型类型只在编译时检查。在运行时,Class<Get<T>>
永远是Get.class
.
关于这个主题的一些相关问题:
关于java - 在 Android 中将嵌套的 Class<MyInterface<T>> 作为参数传递,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36443094/