用於創建一組數據對象的設計模式

Question

我正在編寫一些代碼來執行某些操作，而且我非常肯定它目前沒有很好的設計，但我無法考慮應該如何重構它才能使它更好...

簡單的總結是，我有一些代碼通過目錄結構中的一些文件，不同的目錄包含不同的內容類型。我有這些內容類型的數量有限，而且目前我有一個內容類型的對象，我只是創造了很多添加到列表的方式，例如如下：

 contentTypes.Add(new ContentType { ContentName = "2010 Call Report", FolderName = "2010 Reports", RenameFile = false }); 
     contentTypes.Add(new ContentType { ContentName = "2010 Email Report", FolderName = "2010 Reports", RenameFile = false }); 
     contentTypes.Add(new ContentType { ContentName = "Above Average Call Recording", FolderName = "Call Recordings", RenameFile = true, HasMultiple = true }); 
     contentTypes.Add(new ContentType { ContentName = "Below Average Call Recording", FolderName = "Call Recordings", RenameFile = true, HasMultiple = true }); 

這真的不覺得對（總共11行代碼實際相同），但我想不出還有什麼我該做的。

ContentType類內容可以看到上面的一些屬性和一個稱爲GetNewFilename的公共方法。目前GetNewFilename方法非常簡單並且由所有內容類型共享。不過，現在我想有幾個ContentType對象有自己的這種方法的版本...

事情我必須考慮的是：

1）子類ContentType創建每個內容類型的類

這對我來說並不合適，因爲我有11個班級，所有這些班級從來沒有改變過他們的信息，而且從來沒有任何一點超過一個。這對於一個班級來說並不是同樣的權利（我知道關於單身人士，但是聽說如果你正在使用他們，你可能會錯誤地把它搞錯）。在ContentType

2）Func財產我想，我可以設置在ContentType委託來處理GetNewFilename功能是不同的，但它仍然那麼凌亂的感覺在上述方式生成它們。

3）工廠類

我以前從來沒有（據我所知）使用工廠類，但我知道他們是用於生成類。我對他們的閱讀表明，這種模式被用於生成不同的子類型，而不僅僅是一組類的實例。

4）配置文件

的數據，因爲我有它上面可以全部放在一個配置文件或數據庫或東西，然後裝起來並循環到更爲很好（這只是剛剛發生在我生成它）但是它仍然不能解決變化的方法的問題。我不確定我可以輕鬆地將代理放置在配置文件中。 :)

5）把所有的上一級

不同getNewFileName方法我可以有內容類有各種不同的方法，我可以想和使用某種選擇，然後選擇是正確的。這似乎也有點不足。

那麼有人可以提出一個好方法來做到這一點？

這是我的ContentType類的當前簽名（邏輯刪除 - 詢問您是否認爲其相關）。

public class ContentType 
{ 
    public string ContentName { get; set; } 
    public string FolderName { get; set; } 
    public bool RenameFile { get; set; } 
    public bool HasMultiple { get; set; } 

    public string GetNewFilename(string originalFilename, int fileIndex) 
    {...} // This method needs to do diffent things for different contenttypes 
} 

如果你想要這個類是如何使用，那麼請問，我可以將其粘貼在，但我不想淹沒在代碼中，我沒想到類的更多細節是相關的。

這只是一個代碼使用（將文件移動到適當的目錄放在一個新的網站，並確保他們正確命名），所以最好的代碼並不重要，但它會去bug我if我至少不知道我應該做什麼。如果正確的方式看起來會花很長時間（例如從頭開始重寫代碼），那麼我不會打擾，但至少我會知道下一次。 :)

P.S.我現在也意識到，建立一個或兩個構造函數來設置這些初始值並使它們只讀是一個適當的修改，但它仍然不能解決我所有的問題。

Answer 1

有你ContentType類是一個基類，使GetNewFilename方法虛。衍生自ContentType類的每種文件類型，可能需要在GetNewFilename方法中進行特殊處理並覆蓋虛擬實現。然後，只需在目錄搜索中找到需要特殊處理的文件類型時，根據需要創建那些繼承類的實例，否則只需創建ContentType類的實例。

public class ContentType 
{ 
    public virtual string GetNewFilename(string originalFilename, int fileIndex) 
    { 
     // get file name here 
    } 
} 

public sealed class SpecialContentType : ContentType 
{ 
    // Inherrits all the properties of ContentType 

    public override string GetNewFilename(string originalFilename, int fileIndex) 
    { 
     // get special file name here 
    } 
} 

Answer 2

要考慮的另一種模式可能是接口或抽象類。是的，你有11個班，但這不一定是壞事。它將保持你的關注清晰分離，同時提供一個通用框架。

如果GetFileName在幾種情況下的工作方式相同，則可以使用虛擬GetFileName方法實現抽象類。這將限制你必須編寫新的代碼量，只在必要時覆蓋：

public abstract class ContentType 
    { 
     public string ContentName { get; set; } 
     public string FolderName { get; set; } 
     public bool RenameFile { get; set; } 
     public bool HasMultiple { get; set; } 

     public virtual string GetFileName() 
     { 
      //Base GetFileName implementation 
      return "filename"; 
     } 
    } 

Answer 3

對於＃4，您可以使用Unity或StructureBuilder等IoC容器。那麼對於第二部分提供了一個類：

public interface INewFilenameService { 
    string FileName {get;set;} 
} 

public class ContentType { 
    private INewFilenameService newFilenameService; 

    public ContentType(INewFilenameService service) { 
     this.newFilenameService = service; 
    } 

    public string ContentName { get; set; } 
    public string FolderName { get; set; } 
    public bool RenameFile { get; set; } 
    public bool HasMultiple { get; set; } 

    public string GetNewFilename() { 
     return service.Filename; 
    } 
} 

，那麼你可以實例化無論是在配置還是在運行時你的內容類型列表。