我想在這種情況下,使用依賴注入Implementation
內實例化類型:依賴注入的循環
public interface Implementable{[...]}
public class Implementation implements Implementable{[...]}
public class DummyClass()
{
private List<Implementable> testList;
public DummyClass()
{
testList = new ArrayList<Implementable>();
for(int i = 0; i < 10; i++)
{
Implementable testVar = new Implementation(i);
testList.add(testVar);
}
}
}
雖然我設法收集多了,這是不可能的。無論是通過構造函數注入還是使用泛型。另外,我更喜歡不依靠外部庫來實現這一目標的本地解決方案。
編輯: 任何解決方案將需要DummyClass
就不會知道哪一個實現的InterfaceType
是在循環內被實例化。
我正在考慮使用泛型,但由於InterfaceType testVar = new T(i);
是不允許的,因此失敗。另外,由於需要參數的構造函數,newInstance()
方法不可行。雖然這仍然是可能的,但它需要太多的反思(getConstructor
)和類型安全性的損失,因爲我對乾淨方法的嘗試。
我非常滿意地聽到我試圖達到的目標無法以任何可推薦的方式實現。這個問題是希望我確實錯過了一些東西。
EDIT2: 我試圖去同一個類似的解決方案的一個由drewmoore提供而是跨越,我沒有想過一個缺陷來了。
接口不聲明構造函數的任何要求。有了這個方法,我將不得不在接口的所有實現中使用相同的構造函數。
這讓我想起了建造者模式。這仍然與界面需要定義構建方法一樣需要警惕,因此需要再次制定所有實現的構建要求。
是否有其他延遲施工方式?也就是說,一種方法可以使我注入我想要使用的實現實例(public DummyClass(InterfaceType implementation)
),但只能在循環內部構建(或構建或初始化)它,然後才能返回它自己的副本。
但話又說回來。我越來越覺得我試圖達到的目標是不可能的。或者不應該因爲不合理的額外複雜性或強加的限制而完成。我可能寧願接受這個類對實現的直接依賴,並感謝drewmoore對她的見解。
的問題是,我也不清楚。你能否添加更多關於你想要實現的細節? – Numbers 2014-10-03 22:25:47
我想'DummyClass'不要依賴'Implementation'。只在接口'InterfaceType'上。我可以看到可能實現的唯一途徑似乎是注入。只有在我的情況下,我不能簡單地注入一個實例並使用它,因爲循環會根據循環計數器創建不同的實例。 – 2014-10-03 22:50:03