構造器的設計模式

我一直在設計問題上受到挑戰，我將在下面進行介紹。構造器的設計模式

假設一個類，稱爲A，有一個帶有一堆參數的構造函數。由於在每個實例化中寫入所有這些參數都很累人，所以我編寫了另一個類，將其稱爲StyleSheetA，它封裝了所有這些參數，並且是構造函數的唯一參數。這樣，我可以準備一些默認值StyleSheetA模板稍後會用到，如果需要的話，我可以修改它們。

在這一點上，我需要擴展A.假設B擴展A. B將有它自己的樣式表，即StyleSheetB。我認爲StyleSheetB擴展StyleSheetA是合適的，所以對於一個樣式表參數，B的構造函數也可以構造它的超類A.但是我擔心這種設計可能存在缺陷。例如，如果我決定爲樣式表添加一個getter/setter？有沒有一種新穎的方式來處理所有這些情況？我錯了嗎？對於那些誰是困惑，我在這裏附上一些代碼：


    class A 
    { 
     StyleSheetA ss; 

     A(StyleSheetA ss) 
     { 
      this.ss = ss; 
      // Do some stuff with ingredients of styleSheet 
     } 
    } 
    class StyleSheetA 
    { 
     int n1; 
     int n2; 
     // : 
     // : 
     int n100; 
    } 

    class B extends A 
    { 
     B(StyleSheetB ss) 
     { 
      super(ss); 
      // Do some stuff with ingredients of styleSheet 
     } 
    } 
    class StyleSheetB extends StyleSheetA 
    { 
     int n101; 
     int n102; 
     // : 
     // : 
     int n200; 
    }

謝謝你的任何幫助或建議，也可以是任何的批評可以理解的。

編輯：我在java中開發，所以沒有泛型支持。

來源

2011-02-09 ozan k

對於我正在開發的語言來說，這並不明顯（但對我而言），但通常泛型/模板可以幫助解決此問題。通過將A類變爲A ，您可以在從中派生類型時指定組合的類型（例如StyleSheetB）：B類延伸A 。如果你沒有這樣的功能，試試C＃;） – 2011-02-09 21:38:46

是的，你的解決方案將是一個很好的方法，但不幸的是我用java開發，並且沒有通用的支持。謝謝。 – 2011-02-09 21:41:42

你應該添加一個java-me標籤。 ;） – weltraumpirat 2011-02-09 21:48:34

您是否考慮過使用IoC容器（如StructureMap）來管理構造函數的依賴關係？這可能會使這件事情變得更容易。

來源

2011-02-09 21:28:41

在我看來，你只是將參數從A級過多到StyleSheetA級的問題。

爲了說明我的觀點，請考慮以下問題：如何實例化StyleSheetA？無論如何，可能使用一個接受所有這些參數的構造函數。此設計可能給您帶來的唯一好處是，如果您有一組由StyleSheetA對象封裝的相同參數值集合，您可以在多個A實例中重複使用該對象。如果是這樣，請記住，雖然你有不同的A實例，但它們會共享相同的參數，所以它不是一個好的選擇。

我可以推薦你的是嘗試重構你的班級A本身。嘗試將其分解成更小的類。如果需要，嘗試創建子類以避免條件分支等。

現在，我不知道您的課程A的外觀如何，但是如果您這樣做，您將擁有幾個類，每個類都有自己的設置的參數。如果任何參數是一個鑑別器（意味着它決定了「類型」類），那麼只需使用子類，並依靠內置類型系統來完成它，就可以擺脫它。

來源

2011-02-09 21:32:05

在吸氣和setter問題甲想法：

在「B」的構造意味着附加參數（N101 +）所必需的類的操作。如果你只是用一個完整的參數列表來擴展這個類，那麼你可以在B和A的n1 ... n100中獲得n101 ... n200的獲得者和設置者。這表明也許沒有StylesheetB擴展StylesheetA，而是讓類B的構造函數爲B(StyleSheetA,StyleSheetB)，這樣你可以在類A中爲它的參數設置一個setter，讓它繼承並且在B中爲StylesheetB放置一個。

來源

2011-02-09 21:44:45 dfb

構造器的設計模式

回答

相關問題