方法签名，泛型滥用？

最近遇到一个选择题，在xmemcached中，get方法原来的签名是这样的：

public Object  get(final String key) throws TimeoutException,InterruptedException,MemcachedException;

 

    那么用户使用的时候，需要自己转型，也就是这样

String value=(String)client.get("key");

 

    后来我将get方法的签名改成了泛型方法，xmemcached帮你做这个转型工作,

public <T> T get(final String key) throws TimeoutException,InterruptedException, MemcachedException;

 

    方法的实现因为有了个转型，不得不加上抑制警告，

  @SuppressWarnings("unchecked")
    public final <T> T get(final String key) throws TimeoutException,
            InterruptedException, MemcachedException {
        return (T) get(key, DEFAULT_OP_TIMEOUT);
    }

 

  这样用户使用的时候，就不需要显式转型，而是xmemcached帮你做了，

String value=client.get("key");

 

后来，我仔细想了这个问题，尽管这里使用了泛型方法，似乎简化了用户的工作，然而却丢掉了编译警告，抑制警告让用户可能忽略这里可能的转型失败，这与泛型 的初衷似乎不符。可是，另一个观点冒出来支持我，用户往memcached存进去一头大象，他（她）不会希望取出来的时候变成驴子，我们帮他做这个转型工 作可以让用户使用起来更简便。你怎么看呢？

支持泛型。

不支持....里面还是强转....

关键是存的时候，要存入大象，不要存入驴子

一次内部强省了很多的外部强转，不是很好啊，大不了抛出爱的异常出来。

应该在插入时进行类型检查.....而不是到出口时强转
另:像memorycache这东西存什么不由客户A来决定
有时会由客户X来决定

memorycache尽量不要抛出异常...

不懂memorycache，异常这么处理还是要看外部代码怎么写的吧，就凭对这段代码的直观感觉，倾向于内部强转。

程序员用这是为提高性能的....要为这报了错..等丢饭碗吧

还是不明白，抛异常是为了发现问题啊，而且这种类型转换的问题不可能是开发的时候正常使用的时候不正常吧，代码写了放大象就大象啊，不会部署的时候变成放驴子吧？

好吧....如果你这么认为
那就这样吧.
把put方法的签名改成一个就是string不好么?
memorycache
没怎么用过
有个公司内开发的...
驴子是真的有