研磨設計模式之工廠方法模式-1——跟着cc學設計系列

更多請搜索「研磨設計模式 跟着cc學設計」

工廠方法模式（Factory Method）

1  場景問題

1.1  導出數據的應用框架

        考慮這樣一個實際應用：實現一個導出數據的應用框架，來讓客戶選擇數據的導出方式，並真正執行數據導出。
        在一些實際的企業應用中，一個公司的系統每每分散在不少個不一樣的地方運行，好比各個分公司或者是門市點，公司沒有創建全公司專網的實力，可是又不肯意讓業務數據實時的在廣域網上傳遞，一個是考慮數據安全的問題，一個是運行速度的問題。
        這種系統一般會有一個折中的方案，那就是各個分公司內運行系統的時候是獨 立的，是在本身分公司的局域網內運行。而後在天天業務結束的時候，各個分公司會導出本身的業務數據，而後把業務數據打包經過網絡傳送給總公司，或是專人把數據送到總公司，而後由總公司進行數據導入和核算。
        一般這種系統，在導出數據上，會有一些約定的方式，好比導出成：文本格式、數據庫備份形式、Excel格式、Xml格式等等。
        如今就來考慮實現這樣一個應用框架。在繼續以前，先來了解一些關於框架的知識。

1.2  框架的基礎知識

(1)：框架是什麼
        簡單點說：框架就是能完成必定功能的半成品軟件。
        就其本質而言，框架是一個軟件，並且是一個半成品的軟件。所謂半成品，就是還不能徹底實現用戶須要的功能，框架只是實現用戶須要的功能的一部分，還須要進一步加工，才能成爲一個知足用戶須要的、完整的軟件。所以框架級的軟件，它的主要客戶是開發人員，而不是最終用戶。
        有些朋友會想，既然框架只是個半成品，那何須要去學習和使用框架呢？學習成本也不算小，那就是由於框架能完成必定的功能，也就是這「框架已經完成的必定的功能」在吸引着開發人員，讓你們投入去學習和使用框架。

(2)：框架能幹什麼
        能完成必定功能，加快應用開發進度
        因爲框架完成了必定的功能，並且一般是一些基礎的、有難度的、通用的功能，這就避免咱們在應用開發的時候徹底從頭開始，而是在框架已有的功能之上繼續開發，也就是說會複用框架的功能，從而加快應用的開發進度。
        給咱們一個精良的程序架構
        框架定義了應用的總體結構，包括類和對象的分割，各部分的主要責任，類和對象怎麼協做，以及控制流程等等。
如今Java界大多數流行的框架，大都出自大師手筆，設計都很精良。基於這樣的框架來開發，通常會遵循框架已經規劃好的結構來進行開發，從而讓咱們開發的應用程序的結構也相對變得精良了。

(3)：對框架的理解
        基於框架來開發，事情仍是那些事情，只是看誰作的問題
        對於應用程序和框架的關係，能夠用一個圖來簡單描述一下，如圖1所示：

 

圖1  應用程序和框架的簡單關係示意圖

 

        若是沒有框架，那麼客戶要求的全部功能都由開發人員本身來開發，沒問題，一樣能夠實現用戶要求的功能，只是開發人員的工做多點。
        若是有了框架，框架自己完成了必定的功能，那麼框架已有的功能，開發人員就能夠不作了，開發人員只須要完成框架沒有的功能，最後一樣是完成客戶要求的全部功能，可是開發人員的工做就減小了。
        也就是說，基於框架來開發，軟件要完成的功能並無變化，仍是客戶要求的全部功能，也就是「事情仍是那些事情」的意思。可是有了框架事後，框架完成了一部分功能，而後開發人員再完成一部分功能，最後由框架和開發人員合起來完成了整個軟件的功能，也就是看這些功能「由誰作」的問題。

         基於框架開發，能夠不去作框架所作的事情，可是應該明白框架在幹什麼，以及框架是如何實現相應功能的
        事實上，在實際開發中，應用程序和框架的關係，一般都不會如上面講述的那樣，分得那麼清楚，更爲廣泛的是相互交互的，也就是應用程序作一部分工做，而後框架作一部分工做，而後應用程序再作一部分工做，而後框架再作一部分工做，如此交錯，最後由應用程序和框架組合起來完成用戶的功能要求。
        也用個圖來講明，如圖2所示：

 

圖2  應用程序和框架的關係示意圖

        若是把這個由應用程序和框架組合在一塊兒構成的矩形，看成最後完成的軟件。試想一下，若是你不懂框架在幹什麼的話，至關於框架對你來說是個黑盒，也就是至關於在上面圖2中，去掉框架的兩塊，會發現什麼？沒錯，剩下的應用程序是支離破碎的，是相互分隔開來的。
        這會致使一個很是致命的問題，整個應用是如何運轉起來的，你是不清楚的，也就是說對你而言，項目已經失控了，從項目管理的角度來說，這是很危險的。
        所以，在基於框架開發的時候，雖然咱們能夠不去作框架所作的事情，可是應該搞明白框架在幹什麼，若是條件許可的話，還應該搞清楚框架是如何實現相應功能的，至少應該把大體的實現思路和實現步驟搞清楚，這樣咱們才能總體的掌控整個項目，才能儘可能減小出現項目失控的狀況。

(4)：框架和設計模式的關係
        設計模式比框架更抽象
       框架已是實現出來的軟件了，雖然只是個半成品的軟件，但畢竟是已經實現出來的了。而設計模式的重心還在於解決問題的方案上，也就是還停留在思想的層面。所以設計模式比框架更爲抽象。
      

       設計模式是比框架更小的體系結構元素
       如上所述，框架是已經實現出來的軟件，並實現了一系列的功能，所以一個框架，一般會包含多個設計模式的應用。

        框架比設計模式更加特例化
       框架是完成必定功能的半成品軟件，也就是說，框架的目的很明確，就是要解決某一個領域的某些問題，那是很具體的功能，不一樣的領域實現出來的框架是不同的。
      而設計模式還停留在思想的層面，在不一樣的領域均可以應用，只要相應的問題適合用某個設計模式來解決。所以框架老是針對特定領域的，而設計模式更加註重從思想上，從方法上來解決問題，更加通用化。

1.3  有何問題
       分析上面要實現的應用框架，無論用戶選擇什麼樣的導出格式，最後導出的都是一個文件，並且系統並不知道究竟要導出成爲何樣的文件，所以應該有一個統一的接口，來描述系統最後生成的對象，並操做輸出的文件。
       先把導出的文件對象的接口定義出來，示例代碼以下：

 

 

/** * 導出的文件對象的接口 */ public interface ExportFileApi {     /**     * 導出內容成爲文件     * @param data 示意：須要保存的數據     * @return 是否導出成功     */     public boolean export(String data); }

        對於實現導出數據的業務功能對象，它應該根據須要來建立相應的ExportFileApi的實現對象，由於特定的ExportFileApi的實現是與具體的業務相關的。可是對於實現導出數據的業務功能對象而言，它並不知道應該建立哪個ExportFileApi的實現對象，也不知道如何建立。
        也就是說：對於實現導出數據的業務功能對象，它須要建立ExportFileApi的具體實例對象，可是它只知道ExportFileApi接口，而不知道其具體的實現。那該怎麼辦呢？