良好的構造函數設計

一般來說，在構造函數中構造其他對象是不是一個好主意（我通常不喜歡它）？假設類型A的對象需要類型B的實例。類型B的實例應該是靜態的，因爲我真的只需要它的一個副本......真的......不，認真。類型b還會引發類型A需要處理的事件。類型B位於我無法控制的外部庫中。讓我的B型對象靜態看起來像是在測試時會感到煩惱。我本來想讓A完全靜態的，因爲它基本上是B的代理。也許這是真正的問題。當代理對象需要初始化時，什麼是良好的代理設計？我能想到的至少有三個辦法：良好的構造函數設計

傳入的參數需要構造類型A型B.沿 A類的構造函數然後構造類型B.（調用創建方法從返回B型在構造函數中是相同的基本概念。
傳遞一個構造的對象。
創建一個initialize方法。

我不喜歡選項1，因爲它只是複雜的。我會做所有類型的B初始化代碼，設置前夕NT處理程序等。我不喜歡選項2，因爲我不希望外部世界知道這種依賴關係。 A類是唯一能夠與B類交互的類型。通常，我不喜歡初始化方法，或者「保護」封裝依賴狀態的方法。我似乎最終得到了很多這樣的代碼：

if (typeB != null && typeB.State != Unitialized)

Yuck。

這是我正在使用的一些示例代碼。只是尋找如何使這個真正乾淨，簡單和易於維護。

public class A 
    { 
     private static readonly ILog log = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); 
     private B b; 

     public new A(string productName, string serviceName) 
     { 
      b = new B 
      { 
       ProductName = productName, 
       ServiceName = serviceName 
      }; 

      b.SomethingHappened += b_HandleIt;

UPDATE： 我要回答的註釋的參考this pragmatic article。我熟悉DI，IoC，工廠方法，構建器模式，構造器注入，方法注入，屬性注入，測試驅動設計等等。我想我的問題是，如何儘可能少地編寫簡單性和優秀設計並儘可能快地抵制我目前的需求？ B類將永遠不會被替換，除了A類將在我的項目中使用B類之外，我沒有理由相信任何東西。我對測試的接縫有點擔心，但A類非常簡單，代碼少，基本上包裝了第三方類。

來源

2014-12-27 kakridge

相關對象應該被傳入/注入施工對象中。使用工廠方法來封裝需要大量依賴項的對象的複雜構造。構造函數簽名指的是接口而不是混凝土。 –

我明白你對選項2的問題，但這些都是虛假的擔憂。看看依賴注入，例如HTTP：//www.codeproject。com/Articles/615139/An-Absolute-Beginners-Tutorial-on-Dependency-Inver選項2（傳遞構造對象）是我認爲的方法。 – hschne

http://essentials.xebia.com/kiss/？這些類不需要多態性，我希望它們緊密結合。爲什麼這些問題是錯誤的？ – kakridge

使用構造器注入結束了DI。並不是絕對的興奮，但它似乎是最直接的方法。

來源

2015-01-15 05:12:39 kakridge

-1

如果你真的只需要一個類型b的實例，那麼你爲什麼要將它作爲A的構造的一部分來處理？它應該是B類的類成員，並且您可以在需要時從B類獲得它。類A的一個實例不需要它自己的指向b的指針。（因爲只有一個實例，所以它沒有任何意義，因爲它有自己的b實例。）

來源

2014-12-27 07:23:52 ganbustein

也許我的文字不太清楚。 A類包含B類的一個實例，我不能修改B類。 – kakridge

良好的構造函數設計

回答

相關問題