Keywords: Factory Pattern, Design Pattern

在網上經常會看到有關Factory Pattern的文章, 今天我也在blog上發表一下對一個非常簡單Factory pattern的見解.

Factory模式其實就是為了封裝系統的變化點, 將變化點集中在一起, 一旦這些變化點真的發生變化時, 只要修改一處代碼就可以了.


一圖勝萬言, figure1是表述這樣的一個應用: (1)用戶選擇一個壓縮文件, 然后解壓. (2)用戶選擇一個壓縮文件, 然后將它轉換成自解壓格式. 面對這樣的需求, 我們該做什么樣的結構設計呢?

figure1

初步設計是: 目前流行的壓縮格式有zip和rar等. 我們會抽象一個壓縮格式處理器這樣的基類(命名為CompressBase), 不同壓縮格式的解壓和壓縮算法不同, 所以我們又會設計出CompressBase的幾個派生類, 比如ZipCompress和RarCompress. 用戶可能會選擇一個zip文件需要我們處理, 也可能選擇一個rar文件. 在程序中, 到底要實例化哪個派生類呢? 一個簡單的方法是, 通過文件的擴展名, 作為判斷的依據. 最開始, 實現Scenario A中的代碼為:

public void Decompress(string fileName)

{

CompressBase compressObj=null ;

string fileExtenstion= FileHelper.GetExtension(fileName) ;

switch (fileExtenstion)

{

case "zip":

{

compressObj= new ZipCompress(fileName);

break ;

}

case "rar"


{

compressObj= new ZipCompress(fileName);

break ;

}

default:

{

return ;

}

}



//uncompress the file


compressObj.Decompress() ;

}

同樣, 在實現Scenario B的MakeSelfExe()也和上面代碼相似. 這樣做有什么問題呢? 問題之一, 如果系統要增加對7zip格式的支持, 需要修改所有生成CompressBase對象的地方. 問題之二, 如果我們不采用通過文件擴展名來判斷壓縮格式的方法, 而是采用更好的算法時, 也需要在程序中到處修改生成CompressBase對象的代碼.

較好的設計方案是: 設計一個Factory類, 它具有一個靜態的CreateInstance(string fileName), 該方法封裝了生成CompressBase類的算法. 剛開始可以繼續采用根據擴展名來生成不同的CompressBase子類. 在要生成 即使將來更新算法或增加新的壓縮格式, 也只需要更新CreateInstance().

適用性:

(1) 如果可以確定一個系統中, 僅有Scenario A這個場合, 不會有其他類似的功能, 就沒有必要使用這種模式.

(2) 對于Scenario A, 這個場景的入口是唯一的. 如果操作的入口和派生類的個數一樣的話, 也沒有必要使用這種模式, 比如在畫圖程序中, 雖然Triangle類和Rectangle類都是Shape類的子類, 但畫圖程序的工具面板上有畫三角和矩形兩個ToolButton, 也沒有必要再創建一個Factory類來負責生成派生類對象.

轉載于:https://www.cnblogs.com/harrychinese/archive/2011/08/28/2156481.html

總結

以上是生活随笔為你收集整理的Understand one Simple Factory Pattern的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。