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

這是一個簡單的簡化序列化。 我會說，如果適合您的目的，這很好。