java設計模式-簡單工廠模式

1、NET設計模式(1): 簡單工廠模式 最近一直在看設計模式，想把自己的學習筆記與大家分享一下，如果能幫助大家的話，我會非常高興，同時也歡迎大家指出里面的不足。園子里其實關于此類文章已經(jīng)很多了，如果dudu感覺放在首頁欠妥的話，可以調(diào)一下。簡單工廠模式（Simple Factory Pattern）介紹：簡單工廠模式不能說是一個設計模式，說它是一種編程習慣可能更恰當些。因為它至少不是Gof23種設計模式之一。但它在實際的編程中經(jīng)常被用到，而且思想也非常簡單，可以說是工廠方法模式的一個引導，所以我想有必要把它作為第一個講一下。引入：我們在編程的時候，每當"new"一個對象之后，

2、這個對象就依賴于這個類了。如果在后期的維護過程中由于某些原因需要修改一下這個類，則唯一的做法就是打開源代碼，進行修改，修改所有與這個對象有關的操作。這對我們是非常不利的。問題出來了：對象不能應對“具體實例化類型”的變化解決思路：套用一下李建忠李老師的話，封裝變化點，哪里變化，封裝哪里。在這個例子中，要實例化的類變了，就將實例化這個操作封裝起來，我們可以把"new"這個操作移交一個具體的類，由它去負責根據(jù)我們的條件創(chuàng)建具體類的實例，也就是下面要說的“簡單工廠模式”。定義：專門定義一個類來負責創(chuàng)建其他類的實例，被創(chuàng)建的實例通常都具有共同的父類或接口。簡單工廠模式又稱為靜態(tài)工廠方

3、法（Static Factory Method）模式，屬于類的創(chuàng)建型模式，通常根據(jù)一個條件（參數(shù)）來返回不同的類的實例。意圖：提供一個類，由它負責根據(jù)一定的條件創(chuàng)建某一具體類的實例參與者： · 工廠角色（Creator）是簡單工廠模式的核心，它負責實現(xiàn)創(chuàng)建所有具體產(chǎn)品類的實例。工廠類可以被外界直接調(diào)用，創(chuàng)建所需的產(chǎn)品對象。 · 抽象產(chǎn)品角色（Product）是所有具體產(chǎn)品角色的父類，它負責描述所有實例所共有的公共接口。 · 具體產(chǎn)品角色（Concrete Product）繼承自抽象產(chǎn)品角色，一般為多個，是簡單工廠模式的創(chuàng)建目標。工廠類返回的都是該角色的某一具體產(chǎn)品

4、。 UML圖：現(xiàn)實生活中例子：每次參加不同的聚會或者與不同的人見面，可能穿的衣服是不一樣的，比如，你今天上午要與你的一個新客戶見面，你可能會對你的老婆說：老婆，給拿件商務裝（參數(shù)），我要去見我的一個客戶，你老婆（工廠類）接到你的請求（商務裝參數(shù)）后，從衣柜中取出一件商務裝（具體產(chǎn)品），交給你。整個過程就完成了。分析：你可能根據(jù)不同的條件，要的衣服是不一樣的，但要的衣服都是已經(jīng)在你的衣柜中存在的。并且，每件上衣它們都屬于同一種抽象，即它們可以從一個抽象類或接口中繼承，這此衣服各自都有一定特征，這些都是條件。然后你要的時候，就可以向你老婆說一種特征，她就會根據(jù)這個特征為你服務了。這就是典型的簡單工

5、廠模式的應用。 抽象產(chǎn)品類代碼1    /*/ <summary>2    / 抽象產(chǎn)品類:上衣3    / </summary>4    public interface ICoat5    6        void Ge

6、tYourCoat();7      非常簡單，是吧？這里我只是舉一個僅僅能說明問題的例子，在具體的項目中，可能是很復雜的哦。具體產(chǎn)品類代碼 1namespace SimpleFactory 2 3    /*/ <summary> 4    / 具體產(chǎn)品類：商務上衣 5    / </summary> 

7、6    public class BusinessCoat:ICoat 7     8        public void GetYourCoat() 9        10         &#

8、160;  Console.WriteLine("商務上衣");11        12    1314    /*/ <summary>15    / 具體產(chǎn)品類：時尚上衣16    / </summary>17    pu

9、blic class FashionCoat : ICoat18    19        /*/ <summary>20        / 實現(xiàn)ICoat中定義的方法21        / </summary>22 

10、;       / <returns></returns>23        public void GetYourCoat()24        25            Console.Wr

11、iteLine("時尚上衣");26        27    28簡單工廠模式中最核心的部分：工廠類 1namespace SimpleFactory 2 3    /*/ <summary> 4    / 簡單工廠模式中的核心部分:工廠類 5   

12、60;/ </summary> 6    public class Factory 7     8        public ICoat CreateCoat(string styleName) 9        10  &#

13、160;         switch (styleName.Trim().ToLower()11            12                case "business":

14、13                    return new BusinessCoat();14                case "fashion":15  

15、                  return new FashionCoat();16                default :17       &

16、#160;            throw new Exception("還沒有你要的那種衣服");18            19        20    21再看一下客戶在調(diào)用的時候的代碼&#

17、160;1 /*/ <summary> 2    / 客戶類 3    / </summary> 4    class Client 5     6        static void Main(string

18、60;args) 7         8            ICoat food; 9            try10         

19、0;  11                Factory factory = new Factory();1213                Console.Write("我要的是時尚上衣t")

20、;14                food = factory.CreateCoat("fashion");15                food.GetYourCoat();1617    

21、;        18            catch (Exception ex)19            20            

22、;    Console.WriteLine(ex.Message);21            22        23    到這里，代碼就完成了。在客戶端的代碼中有我們就可以根據(jù)具體的參數(shù)，返回我們希望返回的對象，將"new"操作推遲到工廠類中實現(xiàn)。這里，參數(shù)我直接寫上了，我們其實可以將這個參

23、數(shù)寫到一個xml文件中，如app.config文件中，動態(tài)的讀出來，需要穿另外一種衣服了，只需要打開app.config文件，修改里面的值就行了，不需要項目重新編譯。這樣這個小程序就能夠適應一定的變化了（在上傳上去的代碼中我會修改一下）。其實它也是設計模式正要解決的問題，在不修改代碼的情況下，使項目能夠適應一定的客戶需求變化。注意，是一定的，并非全部。優(yōu)點：· 簡單工廠模式能夠根據(jù)外界給定的信息，決定究竟應該創(chuàng)建哪個具體類的對象。通過它，外界可以從直接創(chuàng)建具體產(chǎn)品對  象的尷尬局面中擺脫出來。 · 外界與具體類隔離開來，偶合性低。 · 明確區(qū)分了各自的職

24、責和權力，有利于整個軟件體系結構的優(yōu)化。 缺點：· 工廠類集中了所有實例的創(chuàng)建邏輯，容易違反GRASPR的高內(nèi)聚的責任分配原則  · 雖然簡單工廠模式能夠適應一定的變化，但是它所能解決的問題是遠遠有限的。它所能創(chuàng)建的類只能是事先教考慮到的，如果需要添加新的類，則就需要改變工廠類了。（這個問題在下一個工廠方法模式將得到很好的解決） 應用情景· 工廠類負責創(chuàng)建的對象比較少  · 客戶只知道傳入了工廠類的參數(shù)，對于始何創(chuàng)建對象（邏輯）不關心  參考資料 · 深入淺出設計模式(C#/Java版)  清華大學出版社

25、  · MSDN Webcast  C#面向對象設計模式縱橫談 李建忠老師 源程序下載：/Files/anlyren/SimpleFactory.rarBY-fangang在上一章（原創(chuàng)）一個優(yōu)秀軟件開發(fā)人員的必修課：GRASP（2）低耦合中我聊了聊低耦合，今天我想再聊聊與低耦合休戚相關、GRASP的另一個重要的模式：高內(nèi)聚。2.高內(nèi)聚（High Cohesion）高內(nèi)聚是另一個普遍用來評判軟件設計質量的標準。內(nèi)聚，更為專業(yè)的說法叫功能內(nèi)聚，是對軟件系統(tǒng)中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內(nèi)的任務，沒有其它過多的工作，那么該元素

26、就具有高內(nèi)聚性，反之則為低內(nèi)聚性。高內(nèi)聚要求軟件系統(tǒng)中的各個元素具有較高的協(xié)作性，因為在我們在完成軟件需求中的一個功能，可能需要做各種事情，但是具有高內(nèi)聚性的一個元素，只完成它職責內(nèi)的事情，而把那些不在它職責內(nèi)的事情拿去請求別人來完成。這就好像，如果我是一個項目經(jīng)理，我的職責是監(jiān)控和協(xié)調(diào)我的項目各個階段的工作。當我的項目進入需求分析階段，我會請求需求分析員來完成；當我的項目進入開發(fā)階段，我會請求軟件開發(fā)人員來完成；當我的項目需要測試的時候，我會請求測試人員。如果我參與了開發(fā)，我就不是一個高內(nèi)聚的元素，因為開發(fā)不是我的職責。我們的項目為什么要高內(nèi)聚呢？我覺得可以從可讀性、復用性、可維護性和易變更

27、性四個方面來理解。1可讀性一個人寫文章、講事情，條理清晰才能易于理解，這同樣發(fā)生在讀寫軟件代碼上。如果一堆代碼寫得一團亂麻，東一個跳轉西一個調(diào)用，讀它的人會感覺非常頭疼。這種事情也許一直在寫程序的你我都曾經(jīng)有過經(jīng)歷。如果一段程序條理非常清晰，每個類通過名稱或說明都能清楚明白它的意義，類的每個屬性、函數(shù)也都是易于理解的它所應當完成的任務和行為，這段程序的可讀性必然提高。在軟件產(chǎn)業(yè)越來越密集，軟件產(chǎn)業(yè)中開發(fā)人員協(xié)作越來越緊密、分工越來越細的今天，軟件可讀性的要求相信也越來越為人們所重視。2復用性在軟件開發(fā)中，最低等級的復用是代碼拷貝，然后是函數(shù)的復用、對象的復用、組件的復用。軟件開發(fā)中最懶的人是最

28、聰明的人，他們總是想到復用。在代碼編寫的時候突然發(fā)現(xiàn)某個功能是曾經(jīng)實現(xiàn)過的功能，直接把它拷貝過來就ok了。如果這段代碼在同一個對象中，那么就提出來寫一個函數(shù)到處調(diào)用就行了。如果不是在同一個對象中呢，就將其抽象成一個對象到處調(diào)用吧。如果不在一個項目中呢，那就做成組件給各個項目引用吧。代碼復用也使我們的代碼在復用的過程中不斷精化、不斷健壯、提高代碼質量。代碼的復用的確給我們的開發(fā)帶來了不少便利，但是一段代碼能否在各個需要的地方都能復用呢？這給我們的軟件開發(fā)質量提出了新的要求：好的代碼可以復用，不好的則不行。軟件中的一個對象如果能保證能完成自己職能范圍內(nèi)的各項任務，同時又不去理會與自己職能無關的其它

29、任務，那么它就能夠保證功能的相對獨立性，也就可以脫離自己所處的環(huán)境而復用到其它環(huán)境中，這是一個具有內(nèi)聚性的對象。3可維護性和易變更性在前面如何在struts+spring+hibernate的框架下構建低耦合高內(nèi)聚的軟件中我提到，我們現(xiàn)在的軟件是在不斷變更的，這種變更不僅來自于我們的客戶，更來自于我們的市場。如果我們的軟件通過變更能及時適應我們的市場需求，我們就可以在市場競爭中獲勝。如何能及時變更以適應我們的市場呢，就是通過調(diào)整軟件的結構，使我們每次的變更付出的代價最小，耗費的人力最小，這種變更才最快最經(jīng)濟。高內(nèi)聚的軟件，每個系統(tǒng)、模塊、類的任務都高度相關，就使每一次的變更涉及的范圍縮小到最小。比如評審表發(fā)生了變更，只會與評審表對象有關，我們不會去更改其它的對象。如果我們能做到這一點，我們的系統(tǒng)當然是可維護性好、易變更性好的系統(tǒng)。 那么，我們?nèi)绾巫龅礁邇?nèi)聚呢？就拿前面我提到的評審項目舉例。我現(xiàn)在要為“評審表”對象編寫一段填寫并保存評審表的代碼。評審表對象的職責是更新和查詢評審表的數(shù)據(jù)，但是在顯示一個要填寫的評審表的時候，我需要顯示