Java反射模式不好？

Question

假设我有很多类似的类（在此示例中为RTS中的Units），即Unit类，以及子类UnitA ， UnitB ， UnitC等。

所有Unit类都具有以下构造函数（包括Unit）

public class UnitX {
    public UnitX(FileReader fr) {
         ...read parameters for constructing the unit...
    }
}

我的包含参数的文件具有以下形式

UnitX params
UnitY params
....

并在文件中创建所有单位的列表将是一个while循环，例如

Class[] params = {FileReader.class};
while(fr has more to read) {
    String unitType = fr.getString();
    Unit u = (Unit)
java.lang.reflect.Constructor constr = Class.forName(unitType).getConstructor(params);
    Unit u = (Unit)constr.newInstance(new Object[]{fr});
    list.add(u);
}

我意识到从文件创建对象时经常使用这种模式。 我的问题是，这是一个不好的模式吗？ 有一个更好的方法吗？

Answer 1

这是工厂模式的一种情况：

java.lang.reflect.Constructor constr = Class.forName(unitType).getConstructor(params);
Unit u = (Unit)constr.newInstance(new Object[]{fr});

可以变成

Unit u = UnitFactory.create( unitType, fr );

然后，工厂是if / else的列表。

Answer 2

代码本身很好。 由于构造函数不能成为传统的编码接口的一部分，因此，下一个最好的事情就是一致的反射接口。

但是，如果您在许多地方重复此代码，那不是很好。 您可以尝试将其集中到某种工厂或生成器中，该工厂或生成器提供文件中的单元名称以及为该单元定义的参数，并将其与处理程序实现配对，该处理程序实现将通过UnitFactory提供的参数实例化该单元。 UnitFactory使用反射实例化命名的Unit并为其提供参数。

这允许重用，并使读取文件与实例化以及实例化方法脱钩。

Answer 3

我认为您的实施还可以。 另一种方法：文本文件是DSL （特定于域的语言）的一种简单形式

您可以切换到更具动态性的jvm兼容语言。 诸如groovy（我最喜欢的;-)，javascript（Rhino，...），BeanShell，jython等动态语言可以更轻松地用于实现特定于域的语言（DSL）。 对于更复杂的DSL，可以看一下Eclipse XText项目。

Answer 4

这是一个简单的简化序列化。 我会说，如果适合您的目的，这很好。