2011-12-05 83 views
2

我目前使用這裏定義生成器模式:如何使用構建器模式構建各種類似的對象類型?

Previous question showing my use of the builder pattern

現在我遇到的問題是創建如下結構的要求:

- ZipHolder: file metadata present 
    * File mainFile 
    * File optionalFile 
    * List<File> files 

OR:

- ZipHolder: no file metadata present 
    * File mainFile 
    * File optionalFile 
    * List<File> files 

ZipHolderFile都是由u唱生成器模式,作爲每個靜態類的內部實現。 A ZipHoldermainFile作爲必需的構造函數參數,並預填充ZipHolder中的某些信息,如果需要,可以將其覆蓋。 A File包含與該文件有關的文件內容和關聯的元數據。然後在調用每個Builder類的build()方法時,對ZipHolderFile進行驗證。然後將對象取出並輸出到ZIP文件層次結構,然後根據需要讀入相同的對象結構。

這很好地工作,並在確保不變性的同時給予對象創建的一定程度的靈活性。但我遇到了一個問題。新的要求已經出現,要求File對象可以具有元數據文件內容只有文件內容。我想我可以簡單地將一個布爾標誌值傳遞給ZipHolder對象的構建器,以允許跳過通常的元數據驗證。這似乎確定,但它然後需要構建一個FilemainFile - 基本上,雞和雞蛋的情況。我的下一個想法是將國旗移至File班。這似乎是好的,直到我意識到你可能創建多個File對象,其中一些需要元數據,而另一些對象只有文件內容,並沒有在整個板上強制實施約束的方法。

所以我有點難倒如何繼續。我看不出一種明顯的方式,以優雅的方式將mainFile的要求解耦爲ZipHolder。像抽象類,接口,基類和類似的概念讓人想起,但在這種特殊情況下我需要一些方向。

所以我的問題是:

我可以允許這兩種情況下,同時保持每原因生成器模式在我上面的鏈接?

回答

1

我不太明白這個問題,但你應該做一個類MainFile extends File,在那裏實現約束,並要求用戶將一個MainFile實例傳遞給ZipHolder工廠。

+0

對不起,我遲到的迴應。這個問題或多或少地需要有一個基類的子類。在我的例子中,子類將擁有額外的文件內容。所以我想,考慮到每個File類型的類都有一個內部靜態構建器類,我不太確定如何最好地實現基本上重複的工作。我的構建器模式的目標是不變性,易於使用可選/強制參數構建複雜對象以及驗證。所以我想要更進一步,使用適合我想實現的構建模式。 – speedRS

相關問題