7/7NET設計模式(1):簡潔工廠模式最近始終在看設計模式，想把自己的學習筆記與大家共享一下，如果能幫助大家的話，我會特別高興，同時也歡迎大家指出里面的不足。園子里其實關于此類文章已經很多了，如果dudu感覺放在首頁欠妥的話，可以調一下。

簡潔工廠模式（SimpleFactoryPattern）

介紹：簡潔工廠模式不能說是一個設計模式，說它是一種編程習慣可能更恰當些。由于它至少不是Gof23種設計模式之一。但它在實際的編程中常常被用到，而且思想也特別簡潔，可以說是\o".NET設計模式(2):工廠方法模式盼望對你有所幫助"工廠方法模式的一個引導，所以我想有必要把它作為第一個講一下。

引入：

我們在編程的時候，每當"\o"new與override的區(qū)分"new"一個對象之后，這個對象就依靠于這個類了。如果在后期的維護過程中由于某些緣由需要修改一下這個類，則唯一的做法就是打開源代碼，進行修改，修改全部與這個對象有關的操作。這對我們是特別不利的。

問題出來了：對象不能應對“簡略實例化類型”的變化

解決思路：套用一下李建忠李老師的話，封裝變化點，哪里變化，封裝哪里。在這個例子中，要實例化的類變了，就將實例化這個操作封裝起來，我們可以把"\o"new與override的區(qū)分"new"這個操作移交一個簡略的類，由它去負責依據我們的條件創(chuàng)建簡略類的實例，也就是下面要說的“簡潔工廠模式”。

定義：

專門定義一個類來負責創(chuàng)建其他類的實例，被創(chuàng)建的實例通常都具有共同的父類或接口。簡潔工廠模式又稱為靜態(tài)工廠方法（StaticFactoryMethod）模式，屬于類的創(chuàng)建型模式，通常依據一個條件（參數）來返回不同的類的實例。

意圖：

供應一個類，由它負責依據肯定的條件創(chuàng)建某一簡略類的實例

參加者：工廠角色（Creator）

是簡潔工廠模式的核心，它負責實現創(chuàng)建全部簡略產品類的實例。工廠類可以被外界直接調用，創(chuàng)建所需的產品對象。抽象產品角色（Product）

是全部簡略產品角色的父類，它負責描述全部實例所共有的公共接口。簡略產品角色（ConcreteProduct）

繼承自抽象產品角色，一般為多個，是簡潔工廠模式的創(chuàng)建目標。工廠類返回的都是該角色的某一簡略產品。UML圖：

現實生活中例子：

每次參加不同的聚會或者與不同的人見面，可能穿的衣服是不一樣的，比如，你今日上午要與你的一個新客戶見面，你可能會對你的老婆說：老婆，給拿件商務裝（參數），我要去見我的一個客戶，你老婆（工廠類）接到你的懇求（商務裝參數）后，從衣柜中取出一件商務裝（簡略產品），交給你。整個過程就完成了。

分析：

你可能依據不同的條件，要的衣服是不一樣的，但要的衣服都是已經在你的衣柜中存在的。并且，每件上衣它們都屬于同一種抽象，即它們可以從一個抽象類或接口中繼承，這此衣服各自都有肯定特征，這些都是條件。然后你要的時候，就可以向你老婆說一種特征，她就會依據這個特征為你服務了。這就是典型的簡潔工廠模式的應用。

抽象產品類代碼1

///

<summary>

2

///

抽象產品類:上衣

3

///

</summary>

4

public

interface

ICoat

5

{

6

void

GetYourCoat();

7

}

特別簡潔，是吧？這里我只是舉一個僅僅能說明問題的例子，在簡略的項目中，可能是很簡單的哦。。

簡略產品類代碼

1namespace

SimpleFactory

2{

3

///

<summary>

4

///

簡略產品類：商務上衣

5

///

</summary>

6

public

class

BusinessCoat:ICoat

7

{

8

public

void

GetYourCoat()

9

{

10

Console.WriteLine("商務上衣");

11

}

12

}

13

14

///

<summary>

15

///

簡略產品類：時尚上衣

16

///

</summary>

17

public

class

FashionCoat

:

ICoat

18

{

19

///

<summary>

20

///

實現ICoat中定義的方法

21

///

</summary>

22

///

<returns></returns>

23

public

void

GetYourCoat()

24

{

25

Console.WriteLine("時尚上衣");

26

}

27

}

28}

簡潔工廠模式中最核心的部分：工廠類

1namespace

SimpleFactory

2{

3

///

<summary>

4

///

簡潔工廠模式中的核心部分:工廠類

5

///

</summary>

6

public

class

Factory

7

{

8

public

ICoat

CreateCoat(string

styleName)

9

{

10

switch

(styleName.Trim().ToLower())

11

{

12

case

"business":

13

return

new

BusinessCoat();

14

case

"fashion":

15

return

new

FashionCoat();

16

default

:

17

throw

new

Exception("還沒有你要的那種衣服");

18

}

19

}

20

}

21}

再看一下客戶在調用的時候的代碼

1

///

<summary>

2

///

客戶類

3

///

</summary>

4

class

Client

5

{

6

static

void

Main(string[]

args)

7

{

8

ICoat

food;

9

try

10

{

11

Factory

factory

=

new

Factory();

12

13

Console.Write("我要的是時尚上衣\t");

14

food

=

factory.CreateCoat("fashion");

15

food.GetYourCoat();

16

17

}

18

catch

(Exception

ex)

19

{

20

Console.WriteLine(ex.Message);

21

}

22

}

23

}

到這里，代碼就完成了。

在客戶端的代碼中有我們就可以依據簡略的參數，返回我們盼望返回的對象，將"\o"new與override的區(qū)分"new"操作推遲到工廠類中實現。

這里，參數我直接寫上了，我們其實可以將這個參數寫到一個xml文件中，如app.config文件中，動態(tài)的讀出來，需要穿另外一種衣服了，只需要打開app.config文件，修改里面的值就行了，不需要項目重新編譯。這樣這個小程序就能夠適應肯定的變化了（在上傳上去的代碼中我會修改一下）。其實它也是設計模式剛要解決的問題，在不修改代碼的情況下，使項目能夠適應肯定的客戶需求變化。注意，是肯定的，并非全部。

優(yōu)點：簡潔工廠模式能夠依據外界給定的信息，決定究竟應該創(chuàng)建哪個具體類的對象。通過它，外界可以從直接創(chuàng)建簡略產品對

象的尷尬局面中擺脫出來。外界與簡略類隔離開來，偶合性低。明確區(qū)分了各自的職責和權力，有利于整個軟件體系結構的優(yōu)化。缺點：工廠類集中了全部實例的創(chuàng)建規(guī)律，容易違反GRASPR的高內聚的責任安排原則

雖然簡潔工廠模式能夠適應肯定的變化，但是它所能解決的問題是遠遠有限的。它所能創(chuàng)建的類只能是事先教考慮到的，如果需要添加新的類，則就需要轉變工廠類了。（這個問題在下一個\o".NET設計模式(2):工廠方法模式盼望對你有所幫助"工廠方法模式將得到很好的解決）應用情景工廠類負責創(chuàng)建的對象比較少

客戶只知道傳入了工廠類的參數，對于始何創(chuàng)建對象（規(guī)律）不關心

參考資料《深化淺出設計模式(C#/Java版)

》清華高校出版社

MSDNWebcast

C#面對對象設計模式縱橫談李建忠老師源程序下載：/BYfangang在上一章《（原創(chuàng)）一個優(yōu)秀軟件開發(fā)人員的必修課：GRASP（2）低耦合》中我聊了聊低耦合，今日我想再聊聊與低耦合休戚相關、GRASP的另一個重要的模式：高內聚。2.高內聚（HighCohesion）高內聚是另一個普遍用來評判軟件設計質量的標準。內聚，更為專業(yè)的說法叫功能內聚，是對軟件系統(tǒng)中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內的任務，沒有其它過多的工作，那么該元素就具有高內聚性，反之則為低內聚性。高內聚要求軟件系統(tǒng)中的各個元素具有較高的協(xié)作性，由于在我們在完成軟件需求中的一個功能，可能需要做各種事情，但是具有高內聚性的一個元素，只完成它職責內的事情，而把那些不在它職責內的事情拿去懇求別人來完成。這就好像，如果我是一個項目經理，我的職責是監(jiān)控和協(xié)調我的項目各個階段的工作。當我的項目進入需求分析階段，我會懇求需求分析員來完成；當我的項目進入開發(fā)階段，我會懇求軟件開發(fā)人員來完成；當我的項目需要測試的時候，我會懇求測試人員。。。。。。如果我參加了開發(fā)，我就不是一個高內聚的元素，由于開發(fā)不是我的職責。我們的項目為什么要高內聚呢？我覺得可以從可讀性、復用性、可維護性和易變更性四個方面來理解。1．可讀性一個人寫文章、講事情，條理清晰才能易于理解，這同樣發(fā)生在讀寫軟件代碼上。如果一堆代碼寫得一團亂麻，東一個跳轉西一個調用，讀它的人會感覺特別頭疼。這種事情也許始終在寫程序的你我都曾經有過經歷。如果一段程序條理特別清晰，每個類通過名稱或說明都能清晰明白它的意義，類的每個屬性、函數也都是易于理解的它所應當完成的任務和行為，這段程序的可讀性必定提高。在軟件產業(yè)越來越密集，軟件產業(yè)中開發(fā)人員協(xié)作越來越緊密、分工越來越細的今日，軟件可讀性的要求信任也越來越為人們所重視。2．復用性在軟件開發(fā)中，最低等級的復用是代碼拷貝，然后是函數的復用、對象的復用、組件的復用。軟件開發(fā)中最懶的人是最聰慧的人，他們總是想到復用。在代碼編寫的時候突然發(fā)現某個功能是曾經實現過的功能，直接把它拷貝過來就ok了。如果這段代碼在同一個對象中，那么就提出來寫一個函數處處調用就行了。如果不是在同一個對象中呢，就將其抽象成一個對象處處調用吧。如果不在一個項目中呢，那就做成組件給各個項目引用吧。代碼復用也使我們的代碼在復用的過程中不斷精化、不斷健壯、提高代碼質量。代碼的復用的確給我們的開發(fā)帶來了不少便利，但是一段代碼能否在各個需要的地方都能復用呢？這給我們的軟件開發(fā)質量提出了新的要求：好的代碼可以復用，不好的則不行。軟件中的一個對象如果能保證能完成自己職能范圍內的各項任務，同時又不去理會與自己職能無關的其它任務，那么它就能夠保證功能的相對獨立性，也就可以脫離自己所處的環(huán)境而復用到其它環(huán)境中，這是一個具有內聚性的對象。3．可維護性和易變更性在前面《如何在struts+spring+hibernate的框架下構建低耦合高內聚的軟件》中我提到，我們現在的軟件是在不斷變更的，這種變更不僅來自于我們的客戶，更來自于我們的市場。如果我們的軟件通過變更能準時適應我們的市場需求，我們就可以在市場競爭中獲勝。如何能準時變更以適應我們的市場呢，就是通過調整軟件的結構，使我們每次的變更付出的代價最小，耗費的人力最小，這種變更才最快最經濟。高內聚的軟件，每個系統(tǒng)、模塊、類的任務都高度相關，就使每一次的變更涉及的范圍縮小到最小。比如評審表發(fā)生了變更，只會與評審表對象有關，我們不會去更改其它的對象。如果我們能做到這一點，我們的系統(tǒng)當然是可維護性好、易變更性好的系統(tǒng)。那么，我們如何做到高內聚呢？就拿前面我提到的評審項目舉例。我現在要為“評審表”對象編寫一段填寫并保存評審表的代碼。評審表對象的職責是更新和查詢評審表的數據，但是在顯示一個要填寫的評審表的時候，我需要顯示該評審計劃的名稱、該評審計劃有哪些評審對象需要評審?，F在我如何編寫顯示一個要填寫的評審表的代碼？我在評審表對象的這個相應的函數中編寫一段查詢評審計劃和評審對象的代碼嗎？假如你這樣做了，你的代碼就不是高內聚的，由于查詢評審計劃和評審對象的數據不是它的職責。正確的方法應當去懇求“評審計劃”對象和“評審對象”對象來完成這些工作，而“評審表”對象只是獵取其結果。另外，如果一個對象要完成一個雖然在自己職責范圍內，但過程特別簡單的任務時，也應當將該任務分解成數個功能相對獨立的子函數來完成。我曾經觀察一個伴侶寫的數百行的一個函數，讓人讀起來特別費勁。同時這樣的函數中一些相對