应该何时接受类类型作为参数?

时间:2011-08-28 14:49:37

标签: java

我已经看到API的设计,它们有时会接受作为参数传递的类类型。 例如[a]:

class AClass {
//details
}

class Someclass {

 public void someMethod(class klass, int num ) {
 // some code
 }

}

class client {

public static void main(String[] args) {
   Someclass obj = new Someclass();
   obj.someMethod(AClass.class, 10); // some sample use cases of client
}

}

现在在java中,如果可以从对象获取类类型,则根本不需要传递类,如下所述[b]

class AClass {
//details
}

class Someclass {

 public void someMethod(AClass obj, int num ) {
 // some code
 }

}

class client {

public static void main(String[] args) {
   Someclass obj = new Someclass();
   AClass aclassObj = new Aclass();
   obj.someMethod(aclassObj, 10); 
}

}

我也可以更改someMethod()的参数并使用下面给出的[c]

public void someMethod(Object obj, int num ) {

 if(obj instanceof AClass) {
  //do something 
 }

}

那么我们何时应该选择[a]中所示的设计而不是[b]?是否有任何一般原则要考虑[a]中所示的设计。

PS:某些API的设计如下所示

Quartz example

3 个答案:

答案 0 :(得分:1)

一些明显的答案是:

  1. 任何时候该方法实际上并不将对象作为参数(例如,当您从DI框架或工厂请求类型的实例时,例如在您提供的Quartz示例中)。
  2. 每次传入的参数可能为空,因此您无法在其上调用getTypeinstanceof也不会表示该对象是instanceof任何类型。< / LI>

    因此,当有问题的方法需要生成有问题的类的实例或提供有关该类的一些元数据(不应该要创建实例)时,采用class参数是有意义的。

    我要指出的唯一另一个考虑因素是,在接受类参数时可以使用泛型,如Guice的Injector接口上的以下方法签名:

    <T> T getInstance(Class<T> type);
    

    注意这是如何允许该方法声明它返回与您作为类参数传入的相同类型的对象,因此您不需要在之后强制转换对象。您还可以使用通用通配符(Class<? extends Foo>)来限制可以传递给方法的类的类型。

答案 1 :(得分:0)

如果需要进行处理,则传递类描述(Class对象)。如果需要对象进行处理,则传递一个对象(该类的实例)。

答案 2 :(得分:0)

另一个例子是here - 返回对象的类型(在这种情况下是列表中的对象)取决于类的类型。

现在可以通过设计使用泛型的API来替换许多需要它的实例,但是对于某些问题,它仍然提供了简洁易懂的语法。