【发布时间】:2012-06-07 18:41:43
【问题描述】:
假设我的班级中有两个构造函数:
public User (List<Source1> source){
...
}
public User (List<Source2> source) {
...
}
假设这两个构造函数都提供了关于用户的相同信息,并且是针对不同用例构造用户的同样有效的方法。
在 Java 中,由于类型擦除,您不能这样做——Java 不会接受两个以 List.
那么,解决这个问题的方法是什么?什么是不矫枉过正但仍然尊重基本 OO 的解决方案?仅仅因为 Java 没有强大的泛型支持,就必须围绕此构造工厂方法或其他接口似乎是错误的。
以下是我能想到的可能性:
1) 接受List<?> 作为构造函数的参数,并在构造函数中解析您需要哪种逻辑,如果不是任何可接受的类型,则抛出异常。
2) 创建一个接受任一 List 的类,构造适当的 User 对象并返回它。
3) 创建围绕 List<Source1> 和 List<Source2> 的包装器,可以改为传递给 User 构造函数。
4) 用两个类子类化这个家伙,除了构造函数之外,所有的功能都被继承了。一个的构造函数接受Source1,另一个接受Source2。
5) 用构建器包装这个人,其中有两种不同的构建器方法,用于实例化的两个不同数据源。
我的问题是:
1) 需要这样做是 Java 的缺陷,还是有意的设计决定?直觉是什么?
2) 在不引入不必要的复杂性的情况下,哪种解决方案在维护良好代码方面最强大?为什么?
这个问题类似:Designing constructors around type erasure in Java,但没有详细说明,它只是提出了各种解决方法。
【问题讨论】:
-
为什么首先要这样做,为什么不对整个班级进行类型参数化?或者只是创建在这种情况下是一个很好的模式的工厂。
-
您可以编写一个函数,然后在函数开头测试列表的类型,然后根据类型进行类型转换...或使用更好的语言
-
...或者您可以使用可具体化的类型,例如数组。
-
为什么有 2 个类的信息相同?为什么它们至少不实现相同的接口?
-
我同意@MarkusMikkolainen 的观点,我会使用工厂模式。我不确定我能回答这是一个缺陷还是设计决定,但它可能与向后兼容性有关。
标签: java type-erasure