在複雜層次注射運行時依賴抽象工廠

ClassA的需要ClassB的
ClassB的需要ClassC

我們得到了一個依賴關係圖如下：

ClassA --> ClassB --> ClassC

所以如果我們使用DI，我們將ClassC和ClassB注入到ClassA中。

但是現在讓我們假設ClassC是一個運行時依賴項（例如某種策略）。建議的方式注入運行時的依賴是引入一個抽象工廠就像一個

ClassCFactory

現在我們可以注入ClassCFactory到ClassB的，並得到如下圖

ClassA --> ClassB --> ClassCFactory

現在我們有一個方法ClassB的其中我們可以打電話讓工廠做好工作。例如

ObjB.SelectC(MyRuntimeValue)

但是現在在我們的應用中，我們不知道什麼ClassB的（或許還有一些涉及更多層）。一種解決方案可能是有SelectC在ClassA的

ObjA.SelectC(MyRuntimeValue) -(calls)-> ObjB.SelectC(MyRuntimeValue)

，或者我們乾脆違反法律德米特和做類似

ObjA.ObjB.SelectC(MyRuntimeValue)

我認爲每個人都同意，第二個解決方案是不是要走的路。但第一個解決方案也有一些缺點，特別是如果我們之間有更多的層。

我們也可以拉出工廠的一個層次來創建ClassB，但是ClassB真的是運行時的依賴關係嗎？你建議什麼解決方案？或者它甚至是一個糟糕的課程設計？

恕我直言，總是更好地依賴於對象實際需要做的工作，而不是創建所需對象的工廠。但有了這個想法一記DI容器將是無用的...

來源

2013-03-25 Christian Metzler

建議的方式注入運行時的依賴是引入一個抽象工廠

你不一定需要一個抽象工廠在運行時注入事物。您可以使用setter注入或方法注入將簡單的依賴關係直接傳遞給對象。

當您必須生成一系列相關對象的對象時，抽象工廠纔是選項系列但直到運行時間才知道哪個系列。你的例子中沒有顯示這種情況，所以YAGNI/KISS將表示不使用它。

但是現在在我們的應用程序中，我們不知道任何關於ClassB （也許涉及到更多的圖層）。

您能否提供一些在您的情況下爲什麼會出現這種情況的詳細信息？對我來說，似乎總會有某種類型的執行上下文知道ClassB並能夠向其中注入C。不過，它不需要與將ClassB注入到A中的執行上下文相同。

IoC也被稱爲好萊塢原則 - "Don't call us, we'll call you"。 "we"是誰以及"call you"部分發生的時間取決於您的應用程序可能會有很大差異，但沒有硬性規定。如果您擔心ObjectA可能對ClassC過於瞭解，只需將其注入委託給其他人。 DI容器可以幫助很多。

來源

2013-03-26 10:18:20 guillaume31

好的，我會給你更具體的含義：ClassC是一個抽象類Encrytption，它對不同類型的加密有不同的實現。 ClassB是一個裝飾器，用Encryption裝飾FileStream。而ClassA是某種可序列化的對象，需要序列化一個流。 – 2013-03-26 10:43:17

什麼決定使用哪種類型的加密？您可以讓ClassA的消費者決定並將3個俄羅斯娃娃放在一起（加密，FileStreeamDecorator和ClassA），或者一些外部對象可以選擇一個加密，將其放入FileStreamDecorator並將其全部傳遞給ClassA的消費者......真的取決於您的上下文。 – guillaume31 2013-03-26 11:28:52

選擇正確的加密取決於我們加載或我們保存。加載時，我們詢問標題，使用哪種加密，然後我們詢問用戶密碼並開始閱讀和解密。在保存時，我們必須使用與加載時相同的加密。有一種特殊的導出方式，用戶最終可以決定使用哪種加密方式。 – 2013-03-26 11:54:56

我發現運行時依賴也很麻煩，我認爲抽象工廠的框架開銷是煩人的額外的代碼，我不希望存在。但是，我還沒有想到一個更好的方式來做這件事。

但是在上面的示例中，我的兩個選擇之間似乎沒有任何顯着差異。

在一種情況下，你有

ObjA.ObjB.SelectC(MyRuntimeValue)

，並在其他你會

ObjA.ObjB.ObjC

這些選項都具有相同的優點和缺點我的腦海裏。正如你注意到的，爲了避免違反得墨忒耳定律，你必須添加許多通過函數。這並不總是值得的，但絕對值得考慮。

來源

2015-09-02 10:21:35 cedd

在複雜層次注射運行時依賴抽象工廠

回答

相關問題