設(shè)計(jì)模式在企業(yè)開(kāi)發(fā)中的應(yīng)用

設(shè)計(jì)模式在企業(yè)開(kāi)發(fā)中的應(yīng)用第一頁(yè)，共68頁(yè)。目標(biāo)深刻理解面向?qū)ο笏枷肜斫饷嫦驅(qū)ο蟮脑O(shè)計(jì)原則掌握常用的設(shè)計(jì)模式掌握設(shè)計(jì)模式的正確使用第二頁(yè)，共68頁(yè)。內(nèi)容提要1什么是面向?qū)ο?面向?qū)ο蟮脑O(shè)計(jì)原則3常用設(shè)計(jì)模式及其應(yīng)用示例第三頁(yè)，共68頁(yè)。一、什么是面向?qū)ο?.1面向?qū)ο蟮氖澜缬^1.2面向?qū)ο蟮姆椒ㄕ?.3面向?qū)ο蟮奶卣鞯谒捻?yè)，共68頁(yè)。1.1面向?qū)ο蟮氖澜缬^ 面向?qū)ο蟮幕菊軐W(xué)是認(rèn)為世界是由各種各樣具有自己的運(yùn)動(dòng)規(guī)律和內(nèi)部狀態(tài)的對(duì)象所組成的； 不同對(duì)象之間的相互作用和通訊構(gòu)成了完整的現(xiàn)實(shí)世界。因此，人們應(yīng)當(dāng)按照現(xiàn)實(shí)世界這個(gè)本來(lái)面貌來(lái)理解世界，直接通過(guò)對(duì)象及其相互關(guān)系來(lái)反映世界。這樣建立起來(lái)的系統(tǒng)才能符合現(xiàn)實(shí)世界的本來(lái)面目。第五頁(yè)，共68頁(yè)。1.2面向?qū)ο蟮姆椒ㄕ? 面向?qū)ο蟮姆椒ㄊ敲嫦驅(qū)ο蟮氖澜缬^在開(kāi)發(fā)方法中的直接運(yùn)用。它強(qiáng)調(diào)系統(tǒng)的結(jié)構(gòu)應(yīng)該直接與現(xiàn)實(shí)世界的結(jié)構(gòu)相對(duì)應(yīng)，應(yīng)該圍繞現(xiàn)實(shí)世界中的對(duì)象來(lái)構(gòu)造系統(tǒng)，而不是圍繞功能來(lái)構(gòu)造系統(tǒng)。第六頁(yè)，共68頁(yè)。1.3面向?qū)ο蟮奶卣鞣庋b繼承多態(tài)第七頁(yè)，共68頁(yè)。1.3面向?qū)ο蟮奶卣鞣庋b每個(gè)對(duì)象都包含它能進(jìn)行操作所需要的所有信息。這個(gè)特性被稱(chēng)為封裝。因此對(duì)象不必依賴(lài)其他對(duì)象來(lái)完成自己的操作。封裝的好處良好的封裝能減少耦合。類(lèi)內(nèi)部的實(shí)現(xiàn)可以自由的修改。類(lèi)具有清晰的對(duì)外接口第八頁(yè)，共68頁(yè)。1.3面向?qū)ο蟮奶卣骼^承對(duì)象的繼承代表了一種“is-a”的關(guān)系，如果兩個(gè)對(duì)象A和B，可以描述為B是A，則表明B可以繼承A。繼承者還可以理解為是對(duì)被繼承者的特殊化，因?yàn)樗司邆淅^承者的特性外，還具備自己獨(dú)有的個(gè)性。繼承的特點(diǎn)子類(lèi)擁有父類(lèi)非privite得屬性和方法。子類(lèi)具有自己的屬性和功能，即子類(lèi)可以擴(kuò)展父類(lèi)沒(méi)有的屬性和功能。子類(lèi)還可以以自己的方式實(shí)現(xiàn)父類(lèi)的功能（方法重寫(xiě)）第九頁(yè)，共68頁(yè)。1.3面向?qū)ο蟮奶卣鞫鄳B(tài)多態(tài)表示不同的對(duì)象可以執(zhí)行相同的動(dòng)作。但需要通過(guò)他們自己的實(shí)現(xiàn)代碼來(lái)執(zhí)行。使用多態(tài)需要注意子類(lèi)以父類(lèi)的身份出現(xiàn)子類(lèi)在工作時(shí)以自己的方式來(lái)實(shí)現(xiàn)子類(lèi)以父類(lèi)的身份出現(xiàn)時(shí)，子類(lèi)特有的屬性和方法不可以使用。為了使子類(lèi)的實(shí)例完全接替來(lái)自父類(lèi)的成員，父類(lèi)必須將其成員聲明為虛擬的（virtual)。子類(lèi)可以通過(guò)override來(lái)重寫(xiě)父類(lèi)的方法。第十頁(yè)，共68頁(yè)?；钭钟∷ⅰ嫦?qū)ο鬄槭裁从∷⑿g(shù)不是四大發(fā)明之一；而活字印刷是四大發(fā)明之一呢？第十一頁(yè)，共68頁(yè)。2面向?qū)ο蟮脑O(shè)計(jì)原則2.1單一職責(zé)原則2.2開(kāi)放封閉原則2.3依賴(lài)倒置原則2.4Liskov替換原則2.5接口隔離原則2.6迪米特法則第十二頁(yè)，共68頁(yè)。2.1單一職責(zé)原則單一職責(zé)原則的核心思想為：一個(gè)類(lèi)，最好只做一件事，只有一個(gè)引起它的變化。單一職責(zé)原則可以看做是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申，將職責(zé)定義為引起變化的原因，以提高內(nèi)聚性來(lái)減少引起變化的原因。職責(zé)過(guò)多，可能引起它變化的原因就越多，這將導(dǎo)致職責(zé)依賴(lài)，相互之間就產(chǎn)生影響，從而大大損傷其內(nèi)聚性和耦合度。通常意義下的單一職責(zé)，就是指只有一種單一功能，不要為類(lèi)實(shí)現(xiàn)過(guò)多的功能點(diǎn)，以保證實(shí)體只有一個(gè)引起它變化的原因。第十三頁(yè)，共68頁(yè)。2.1單一職責(zé)原則示例一、RBAC（基于角色的權(quán)限控制）應(yīng)用設(shè)計(jì)示例二、電話示例第十四頁(yè)，共68頁(yè)。示例一第十五頁(yè)，共68頁(yè)。示例二第十六頁(yè)，共68頁(yè)。2.1單一職責(zé)原則單一職責(zé)的好處類(lèi)的復(fù)雜性降低，實(shí)現(xiàn)什么職責(zé)都有清晰明確的定義可讀性提高，復(fù)雜性降低，那當(dāng)然可讀性提高了可維護(hù)性提高，那當(dāng)然了，可讀性提高，那當(dāng)然更容易維護(hù)了變更引起的風(fēng)險(xiǎn)降低，變更是必不可少的，如果接口的單一職責(zé)做得好，一個(gè)接口修改只對(duì)相應(yīng)的實(shí)現(xiàn)類(lèi)有影響，對(duì)其他的接口無(wú)影響，這對(duì)系統(tǒng)的擴(kuò)展性、維護(hù)性都有非常大幫助第十七頁(yè)，共68頁(yè)。2.2開(kāi)放封閉原則開(kāi)放封閉原則的核心思想是：軟件實(shí)體應(yīng)該是可擴(kuò)展的，而不是可修改的。也就是，對(duì)擴(kuò)展開(kāi)放，對(duì)修改封閉的。開(kāi)放封閉原則主要體現(xiàn)在兩個(gè)方面：1、對(duì)擴(kuò)展開(kāi)放，意味著有新的需求或變化時(shí)，可以對(duì)現(xiàn)有代碼進(jìn)行擴(kuò)展，以適應(yīng)新的情況。2、對(duì)修改封閉，意味著類(lèi)一旦設(shè)計(jì)完成，就可以獨(dú)立完成其工作，而不要對(duì)其進(jìn)行任何的修改。實(shí)現(xiàn)開(kāi)放封閉原則的核心思想就是對(duì)抽象編程，而不對(duì)具體編程，因?yàn)槌橄笙鄬?duì)穩(wěn)定。讓類(lèi)依賴(lài)于固定的抽象，所以修改就是封閉的；而通過(guò)面向?qū)ο蟮睦^承和多態(tài)機(jī)制，又可以實(shí)現(xiàn)對(duì)抽象類(lèi)的繼承，通過(guò)覆寫(xiě)其方法來(lái)改變固有行為，實(shí)現(xiàn)新的拓展方法，所以就是開(kāi)放的?！靶枨罂偸亲兓睕](méi)有不變的軟件，所以就需要用封閉開(kāi)放原則來(lái)封閉變化滿足需求，同時(shí)還能保持軟件內(nèi)部的封裝體系穩(wěn)定，不被需求的變化影響。第十八頁(yè)，共68頁(yè)。2.2開(kāi)放封閉原則在做任何系統(tǒng)時(shí)，都不能指望需求在一開(kāi)始就完全確定。怎樣的設(shè)計(jì)才能面對(duì)需求的改變卻可以保持相對(duì)穩(wěn)定，從而使得系統(tǒng)可以在第一個(gè)版本以后不斷推出新的版本呢？開(kāi)放-封閉原則就是這個(gè)問(wèn)題的答案。軟件設(shè)計(jì)要容易維護(hù)又不容易出問(wèn)題的最好方法就是多擴(kuò)展、少修改絕對(duì)的對(duì)修改關(guān)閉是不可能的。無(wú)論模塊是多么的“封閉”，都會(huì)存在一些無(wú)法對(duì)之封閉的變化。既然不可能完全封閉，設(shè)計(jì)人員必須對(duì)于他設(shè)計(jì)的模塊應(yīng)該對(duì)哪種變化封閉作出選擇。他必須先猜測(cè)出最有可能發(fā)生的變化種類(lèi)，然后構(gòu)造抽象來(lái)隔離那些變化第十九頁(yè)，共68頁(yè)。2.2開(kāi)放封閉原則對(duì)修改封閉原則的應(yīng)用示例//定義1boolConnect(stringuserName,stringpassword,string,intport);//定義2bool

Connect(Account

account);

public

class

Account

{

public

string

UserName

{

get;

set;

}

public

string

Password

{

get;

set;

}

public

string

{

get;

set;

}

public

string

int

Port

{

get;

set;

}

}一般的設(shè)計(jì)原則強(qiáng)調(diào)方法參數(shù)盡量避免基本類(lèi)型第二十頁(yè)，共68頁(yè)。2.2開(kāi)放封閉原則對(duì)擴(kuò)展開(kāi)放的應(yīng)用示例：排序第二十一頁(yè)，共68頁(yè)。2.3依賴(lài)倒置原則依賴(lài)倒置原則的核心思想是：依賴(lài)于抽象。具體而言就是高層模塊不依賴(lài)于底層模塊，二者都同依賴(lài)于抽象；抽象不依賴(lài)于具體，具體依賴(lài)于抽象。依賴(lài)一定會(huì)存在于類(lèi)與類(lèi)、模塊與模塊之間。當(dāng)兩個(gè)模塊之間存在緊密的耦合關(guān)系時(shí)，最好的方法就是分離接口和實(shí)現(xiàn)：在依賴(lài)之間定義一個(gè)抽象的接口使得高層模塊調(diào)用接口，而底層模塊實(shí)現(xiàn)接口的定義，以此來(lái)有效控制耦合關(guān)系，達(dá)到依賴(lài)于抽象的設(shè)計(jì)目標(biāo)。抽象的穩(wěn)定性決定了系統(tǒng)的穩(wěn)定性，因?yàn)槌橄笫遣蛔兊?，依?lài)于抽象是面向?qū)ο笤O(shè)計(jì)的精髓，也是依賴(lài)倒置原則的核心。依賴(lài)于抽象是一個(gè)通用的原則，而某些時(shí)候依賴(lài)于細(xì)節(jié)則是在所難免的，必須權(quán)衡在抽象和具體之間的取舍，方法不是一層不變的。依賴(lài)于抽象，就是對(duì)接口編程，不要對(duì)實(shí)現(xiàn)編程。第二十二頁(yè)，共68頁(yè)。2.3依賴(lài)倒置原則示例：一個(gè)拿C照的司機(jī)能夠開(kāi)Benz小車(chē)一個(gè)拿C照的司機(jī)能夠開(kāi)BMW小車(chē)一個(gè)拿A照的司機(jī)……第二十三頁(yè)，共68頁(yè)。2.3依賴(lài)倒置原則系統(tǒng)的三層架構(gòu)示例第二十四頁(yè)，共68頁(yè)。2.4Liskov替換原則里氏替換原則的核心思想是：子類(lèi)必須能夠替換其基類(lèi)。這一思想體現(xiàn)為對(duì)繼承機(jī)制的約束規(guī)范，只有子類(lèi)能夠替換基類(lèi)時(shí)，才能保證系統(tǒng)在運(yùn)行期內(nèi)識(shí)別子類(lèi)，這是保證繼承復(fù)用的基礎(chǔ)。在父類(lèi)和子類(lèi)的具體行為中，必須嚴(yán)格把握繼承層次中的關(guān)系和特征，將基類(lèi)替換為子類(lèi)，程序的行為不會(huì)發(fā)生任何變化。同時(shí)，這一約束反過(guò)來(lái)則是不成立的，子類(lèi)可以替換基類(lèi)，但是基類(lèi)不一定能替換子類(lèi)。Liskov替換原則，主要著眼于對(duì)抽象和多態(tài)建立在繼承的基礎(chǔ)上，因此只有遵循了Liskov替換原則，才能保證繼承復(fù)用是可靠地。實(shí)現(xiàn)的方法是面向接口編程：將公共部分抽象為基類(lèi)接口或抽象類(lèi)，通過(guò)ExtractAbstractClass，在子類(lèi)中通過(guò)覆寫(xiě)父類(lèi)的方法實(shí)現(xiàn)新的方式支持同樣的職責(zé)。Liskov替換原則是關(guān)于繼承機(jī)制的設(shè)計(jì)原則，違反了Liskov替換原則就必然導(dǎo)致違反開(kāi)放封閉原則。Liskov替換原則能夠保證系統(tǒng)具有良好的拓展性，同時(shí)實(shí)現(xiàn)基于多態(tài)的抽象機(jī)制，能夠減少代碼冗余，避免運(yùn)行期的類(lèi)型判別。第二十五頁(yè)，共68頁(yè)。2.4Liskov替換原則里氏替換原則的經(jīng)典問(wèn)題：正方形不是長(zhǎng)方形鴕鳥(niǎo)非鳥(niǎo)第二十六頁(yè)，共68頁(yè)。2.5接口隔離原則接口隔離原則的核心思想是：使用多個(gè)小的專(zhuān)門(mén)的接口，而不要使用一個(gè)大的總接口。接口隔離原則體現(xiàn)在：接口應(yīng)該是內(nèi)聚的，應(yīng)該避免“胖”接口。一個(gè)類(lèi)對(duì)另外一個(gè)類(lèi)的依賴(lài)應(yīng)該建立在最小的接口上，不要強(qiáng)迫依賴(lài)不用的方法，這是一種接口污染。接口隔離強(qiáng)調(diào)接口的單一性。而胖接口存在明顯的弊端，會(huì)導(dǎo)致實(shí)現(xiàn)的類(lèi)型必須完全實(shí)現(xiàn)接口的所有方法、屬性等；而某些時(shí)候，實(shí)現(xiàn)類(lèi)型并非需要所有的接口定義，在設(shè)計(jì)上這是“浪費(fèi)”，而且在實(shí)施上這會(huì)帶來(lái)潛在的問(wèn)題，對(duì)胖接口的修改將導(dǎo)致一連串的客戶端程序需要修改，有時(shí)候這是一種災(zāi)難。在這種情況下，將胖接口分解為多個(gè)特點(diǎn)的定制化方法，使得客戶端僅僅依賴(lài)于它們的實(shí)際調(diào)用的方法，從而解除了客戶端不會(huì)依賴(lài)于它們不用的方法。分離的手段主要有以下兩種：1、委托分離，通過(guò)增加一個(gè)新的類(lèi)型來(lái)委托客戶的請(qǐng)求，隔離客戶和接口的直接依賴(lài)，但是會(huì)增加系統(tǒng)的開(kāi)銷(xiāo)。2、多重繼承分離，通過(guò)接口多繼承來(lái)實(shí)現(xiàn)客戶的需求，這種方式是較好的。第二十七頁(yè)，共68頁(yè)。2.5接口隔離原則第二十八頁(yè)，共68頁(yè)。2.5接口隔離原則使用接口隔離原則應(yīng)該要注意：接口盡量小，但是要有限度。對(duì)接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性是不掙的事實(shí)，但是如果過(guò)小，則會(huì)造成接口數(shù)量過(guò)多，使設(shè)計(jì)復(fù)雜化。所以一定要適度。為依賴(lài)接口的類(lèi)定制服務(wù)，只暴露給調(diào)用的類(lèi)它需要的方法，它不需要的方法則隱藏起來(lái)。只有專(zhuān)注地為一個(gè)模塊提供定制服務(wù)，才能建立最小的依賴(lài)關(guān)系。提高內(nèi)聚，減少對(duì)外交互。使接口用最少的方法去完成最多的事情。運(yùn)用接口隔離原則，一定要適度第二十九頁(yè)，共68頁(yè)。2.6迪米特法則迪米特法則（LawofDemeter）又叫作最少知識(shí)原則（LeastKnowledgePrinciple簡(jiǎn)寫(xiě)LKP），就是說(shuō)一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其他對(duì)象有盡可能少的了解,不和陌生人說(shuō)話。英文簡(jiǎn)寫(xiě)為:LoD第三十頁(yè)，共68頁(yè)。3常用設(shè)計(jì)模式及其應(yīng)用示例3.1設(shè)計(jì)模式的分類(lèi)3.2單例模式3.3簡(jiǎn)單工廠模式3.4工廠模式3.5策略模式3.6代理模式3.7觀察者模式3.8門(mén)面模式第三十一頁(yè)，共68頁(yè)。3.1設(shè)計(jì)模式的分類(lèi)創(chuàng)建型：創(chuàng)建對(duì)象時(shí)，不再由我們直接實(shí)例化對(duì)象；而是根據(jù)特定場(chǎng)景，由程序來(lái)確定創(chuàng)建對(duì)象的方式，從而保證更大的性能、更好的架構(gòu)優(yōu)勢(shì)。創(chuàng)建型模式主要有簡(jiǎn)單工廠模式（并不是23種設(shè)計(jì)模式之一）、工廠方法、抽象工廠模式、單例模式、生成器模式和原型模式。第三十二頁(yè)，共68頁(yè)。3.1設(shè)計(jì)模式的分類(lèi)結(jié)構(gòu)型用于幫助將多個(gè)對(duì)象組織成更大的結(jié)構(gòu)。結(jié)構(gòu)型模式主要有適配器模式、橋接模式、組合器模式、裝飾器模式、門(mén)面模式、亨元模式和代理模式第三十三頁(yè)，共68頁(yè)。3.1設(shè)計(jì)模式的分類(lèi)行為性用于幫助系統(tǒng)間各對(duì)象的通信，以及如何控制復(fù)雜系統(tǒng)中流程。行為型模式主要有命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態(tài)模式、策略模式、模板模式和訪問(wèn)者模式第三十四頁(yè)，共68頁(yè)。3.2單例模式有些時(shí)候，允許自由創(chuàng)建某個(gè)類(lèi)的實(shí)例沒(méi)有意義，還可能造成系統(tǒng)性能下降。如果一個(gè)類(lèi)始終只能創(chuàng)建一個(gè)實(shí)例，則這個(gè)類(lèi)被稱(chēng)為單例類(lèi)，這種模式就被稱(chēng)為單例模式。單例模式的特點(diǎn)單例類(lèi)只能有一個(gè)實(shí)例單例類(lèi)必須自己創(chuàng)建自己的唯一實(shí)例單例類(lèi)必須給所有其它對(duì)象提供這一實(shí)例第三十五頁(yè)，共68頁(yè)。3.2單例模式單例模式類(lèi)圖：第三十六頁(yè)，共68頁(yè)。3.2單例模式單例模式的常見(jiàn)應(yīng)用場(chǎng)景Windows的TaskManager（任務(wù)管理器）windows的RecycleBin（回收站）網(wǎng)站的計(jì)數(shù)器，一般也是采用單例模式實(shí)現(xiàn)，否則難以同步應(yīng)用程序的日志應(yīng)用，一般都何用單例模式實(shí)現(xiàn)，這一般是由于共享的日志文件一直處于打開(kāi)狀態(tài)，因?yàn)橹荒苡幸粋€(gè)實(shí)例去操作，否則內(nèi)容不好追加Web應(yīng)用的配置對(duì)象的讀取，一般也應(yīng)用單例模式，這個(gè)是由于配置文件是共享的資源HttpApplication也是單位例的典型應(yīng)用…………第三十七頁(yè)，共68頁(yè)。3.2單例模式一個(gè)單例模式應(yīng)用的例子：常用的交流軟件QQ，只能打開(kāi)一個(gè)與某個(gè)人聊天的窗口。第三十八頁(yè)，共68頁(yè)。3.2單例模式單例模式應(yīng)用場(chǎng)景：資源共享的情況下，避免由于資源操作時(shí)導(dǎo)致的性能或損耗等控制資源的情況下，方便資源之間的互相通信。如線程池等第三十九頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式經(jīng)典問(wèn)題：編寫(xiě)一個(gè)計(jì)算器，能夠計(jì)算加減乘除運(yùn)算。第四十頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式從設(shè)計(jì)模式的類(lèi)型上來(lái)說(shuō)，簡(jiǎn)單工廠模式是屬于創(chuàng)建型模式，又叫做靜態(tài)工廠方法（StaticFactoryMethod）模式，但不屬于23種GOF設(shè)計(jì)模式之一。簡(jiǎn)單工廠模式是由一個(gè)工廠對(duì)象決定創(chuàng)建出哪一種產(chǎn)品類(lèi)的實(shí)例。簡(jiǎn)單工廠模式是工廠模式家族中最簡(jiǎn)單實(shí)用的模式，可以理解為是不同工廠模式的一個(gè)特殊實(shí)現(xiàn)。第四十一頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式簡(jiǎn)單工廠模式包含的角色以及職責(zé)：工廠（Creator）角色：簡(jiǎn)單工廠模式的核心，它負(fù)責(zé)實(shí)現(xiàn)創(chuàng)建所有實(shí)例的內(nèi)部邏輯。工廠類(lèi)可以被外界直接調(diào)用，創(chuàng)建所需的產(chǎn)品對(duì)象。抽象產(chǎn)品（Product）角色：簡(jiǎn)單工廠模式所創(chuàng)建的所有對(duì)象的父類(lèi)，它負(fù)責(zé)描述所有實(shí)例所共有的公共接口具體產(chǎn)品（ConcreteProduct）角色：是簡(jiǎn)單工廠模式的創(chuàng)建目標(biāo)，所有創(chuàng)建的對(duì)象都是充當(dāng)這個(gè)角色的某個(gè)具體類(lèi)的實(shí)例。第四十二頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式簡(jiǎn)單工廠模式應(yīng)用示例：聊天軟件對(duì)信息的處理第四十三頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式簡(jiǎn)單工廠模式的優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：工廠類(lèi)是整個(gè)模式的關(guān)鍵.包含了必要的邏輯判斷,根據(jù)外界給定的信息,決定究竟應(yīng)該創(chuàng)建哪個(gè)具體類(lèi)的對(duì)象.通過(guò)使用工廠類(lèi),外界可以從直接創(chuàng)建具體產(chǎn)品對(duì)象的尷尬局面擺脫出來(lái),僅僅需要負(fù)責(zé)“消費(fèi)”對(duì)象就可以了。而不必管這些對(duì)象究竟如何創(chuàng)建及如何組織的．明確了各自的職責(zé)和權(quán)利，有利于整個(gè)軟件體系結(jié)構(gòu)的優(yōu)化。第四十四頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式缺點(diǎn)：由于工廠類(lèi)集中了所有實(shí)例的創(chuàng)建邏輯，違反了高內(nèi)聚責(zé)任分配原則，將全部創(chuàng)建邏輯集中到了一個(gè)工廠類(lèi)中；它所能創(chuàng)建的類(lèi)只能是事先考慮到的，如果需要添加新的類(lèi)，則就需要改變工廠類(lèi)了。當(dāng)系統(tǒng)中的具體產(chǎn)品類(lèi)不斷增多時(shí)候，可能會(huì)出現(xiàn)要求工廠類(lèi)根據(jù)不同條件創(chuàng)建不同實(shí)例的需求．這種對(duì)條件的判斷和對(duì)具體產(chǎn)品類(lèi)型的判斷交錯(cuò)在一起，很難避免模塊功能的蔓延，對(duì)系統(tǒng)的維護(hù)和擴(kuò)展非常不利。第四十五頁(yè)，共68頁(yè)。3.3簡(jiǎn)單工廠模式簡(jiǎn)單工廠模式的應(yīng)用場(chǎng)景：工廠類(lèi)負(fù)責(zé)創(chuàng)建的對(duì)象比較少；客戶只知道傳入工廠類(lèi)的參數(shù)，對(duì)于如何創(chuàng)建對(duì)象（邏輯）不關(guān)心；由于簡(jiǎn)單工廠很容易違反高內(nèi)聚責(zé)任分配原則，因此一般只在很簡(jiǎn)單的情況下應(yīng)用。對(duì)于簡(jiǎn)單工廠模式的缺點(diǎn)，可以在工廠模式中得到克服第四十六頁(yè)，共68頁(yè)。3.4工廠模式將計(jì)算器程序改為工廠模式實(shí)現(xiàn)。第四十七頁(yè)，共68頁(yè)。3.4工廠模式工廠模式的角色以及職責(zé)抽象工廠（Factory）角色：是工廠方法模式的核心，與應(yīng)用程序無(wú)關(guān)。任何在模式中創(chuàng)建的對(duì)象的工廠類(lèi)必須實(shí)現(xiàn)這個(gè)接口。具體工廠（ConcreteCreator）角色：這是實(shí)現(xiàn)抽象工廠接口的具體工廠類(lèi)，包含與應(yīng)用程序密切相關(guān)的邏輯，并且受到應(yīng)用程序調(diào)用以創(chuàng)建產(chǎn)品對(duì)象。抽象產(chǎn)品（Product）角色：工廠方法模式所創(chuàng)建的對(duì)象的超類(lèi)型，也就是產(chǎn)品對(duì)象的共同父類(lèi)或共同擁有的接口。具體產(chǎn)品（ConcreteProduct）角色：這個(gè)角色實(shí)現(xiàn)了抽象產(chǎn)品角色所定義的接口。某具體產(chǎn)品有專(zhuān)門(mén)的具體工廠創(chuàng)建，它們之間往往一一對(duì)應(yīng)。第四十八頁(yè)，共68頁(yè)。3.4工廠模式工廠模式VS簡(jiǎn)單工廠簡(jiǎn)單工廠最大的優(yōu)點(diǎn)在于在工廠中存在必要的邏輯判斷，可以根據(jù)客戶端選擇的條件動(dòng)態(tài)的實(shí)例化相關(guān)的類(lèi)。去除了客戶端對(duì)具體產(chǎn)品的依賴(lài)。但是卻違背了“開(kāi)放-封閉”原則。工廠模式在實(shí)現(xiàn)的時(shí)候，客戶端需要決定實(shí)例化那一個(gè)類(lèi)，選擇判斷的問(wèn)題依舊存在。但是工廠模式將簡(jiǎn)單工廠中在工廠中的判斷放在了客戶端來(lái)進(jìn)行。第四十九頁(yè)，共68頁(yè)。3.4工廠模式最佳實(shí)踐：利用反射利用反射可以去除客戶端的邏輯判斷第五十頁(yè)，共68頁(yè)。3.5策略模式案例：商場(chǎng)的會(huì)員卡制度。商場(chǎng)的會(huì)員卡有銀卡，金卡，白金卡等級(jí)別。而不同的會(huì)員卡在消費(fèi)時(shí)可以享受不同的折扣。第五十一頁(yè)，共68頁(yè)。3.5策略模式策略模式用于封裝系列的算法，這些算法通常被封裝在一個(gè)被稱(chēng)為Context的類(lèi)中，客戶端程序可以自由選擇其中一種算法，或讓Context為客戶端選擇一種最佳算法——使用策略模式的優(yōu)勢(shì)是為了支持算法的自由切換。第五十二頁(yè)，共68頁(yè)。3.5策略模式第五十三頁(yè)，共68頁(yè)。3.5策略模式策略模式的角色以及職責(zé)：環(huán)境（Context）角色：持有一個(gè)Strategy類(lèi)的引用。抽象策略（Strategy）角色：這是一個(gè)抽象角色，通常由一個(gè)接口或抽象類(lèi)實(shí)現(xiàn)。此角色給出所有的具體策略類(lèi)所需的接口。具體策略（ConcreteStrategy）角色：包裝了相關(guān)的算法或行為第五十四頁(yè)，共68頁(yè)。3.5策略模式策略模式與簡(jiǎn)單工廠模式結(jié)合使用第五十五頁(yè)，共68頁(yè)。3.5策略模式策略模式中使用反射第五十六頁(yè)，共68頁(yè)。3.6代理模式代理模式是一種應(yīng)用非常廣泛的設(shè)計(jì)模式，當(dāng)客戶端代碼需要調(diào)用某個(gè)對(duì)象時(shí)，客戶端實(shí)際上不關(guān)心是否準(zhǔn)確得到該對(duì)象，它只要一個(gè)能提供該功能的對(duì)象即可，此時(shí)我們就可返回該對(duì)象的代理（Proxy）代理（Proxy）模式給某一個(gè)對(duì)象提供一個(gè)代理，并由代理對(duì)象控制對(duì)原對(duì)