策略模式（對比工廠模式）

策略模式（對比工廠模式）

從策略一詞來看, 策略模式是種傾向于行為的模式 .有點類似打仗時的做戰(zhàn)方案，一般司令員在做戰(zhàn)前都會根據(jù)實際情況做百科出幾套不同的方案，如果當(dāng)時情況有變，就會根據(jù)相應(yīng)的條件來判定用哪一套方案來替換原定方案。但無論如何替換，替換多少次，仗還是要打的。

策略模式的UML圖 策略(Strategy)模式在結(jié)構(gòu)上與工廠模式類似，**的區(qū)別是工廠模式實例化一個產(chǎn)品的操作是在服務(wù)端來做的 ，換句話說客戶端傳達給服務(wù)端的只是某種標(biāo)識，服務(wù)端根據(jù)該標(biāo)識實例化一個對象。

而策略模式的客戶端傳達給服務(wù)端的是一個實例，服務(wù)端只是將該實例拿過去在服務(wù)端的環(huán)境里執(zhí)行該實例的方法。 工廠模式和策略模式的區(qū)別在于實例化一個對象的位置不同，對工廠模式而言，實例化對象是放在服務(wù)端的，即放在了工廠類里面; 而策略模式實例化對象的操作在客戶端，服務(wù)端的“銷售部門”只負(fù)責(zé)傳遞該對象，并在服務(wù)端的環(huán)境里執(zhí)行特定的操作。 工廠模式要求服務(wù)端的銷售部門足夠靈敏，而策略模式由于對策略進行了封裝，所以他的銷售部門比較傻，需要客戶提供足夠能區(qū)分使用哪種策略的參數(shù)，而這**的就是該策略的實例了。 策略模式的優(yōu)缺點 策略模式的主要優(yōu)點有： 策略模式的缺點主要有兩個： 適用場景 至少在在以下兩種情況下，大家可以考慮使用策略模式， 幾個類的主要邏輯相同，只在部分邏輯的算法和行為上稍有區(qū)別的情況。

有幾種相似的行為，或者說算法，客戶端需要動態(tài)地決定使用哪一種，那么可以使用策略模式，將這些算法封裝起來供客戶端調(diào)用。 策略模式是一種簡單常用的模式，我們在進行開發(fā)的時候，會經(jīng)常有意無意地使用它，一般來說，策略模式不會單獨使用，跟模版方法模式、工廠模式等混合使用的情況比較多。

asp.net 的抽象工廠模式和策略模式怎么看都一樣 誰能解釋下嗎！

這2個區(qū)別比較大吧。策略模式-多個類繼承一個抽象類，每個類都對這個抽象類中的方法做了實現(xiàn)。

這些類都是一種具體的策略。

抽象工廠-多個類繼承一個抽象類，每個類都實現(xiàn)多個產(chǎn)品的實現(xiàn)。打個比方 番茄炒蛋 燒烤，四川師傅，廣東師傅。 四川師傅可以做四川味的炒蛋和燒烤，廣東師傅可以做廣東味的燒烤和炒蛋。

軟件設(shè)計模式主要有哪幾種

軟件設(shè)計模式主要有以下三大類共23種：
一、創(chuàng)建型模式：
1、工廠方法模式
工廠方法模式的創(chuàng)建是因為簡單工廠模式有一個問題，在簡單工廠模式中類的創(chuàng)建依賴工廠類，如果想要拓展程序，必須對工廠類進行修改，這違背了開閉原則，所以就出現(xiàn)了工廠方法模式，只需要創(chuàng)建一個工廠接口和多個工廠實現(xiàn)類。
子類可以自己決定實例化哪一個工廠類，client類針對抽象接口進行編程，如果需要增加新的功能，繼承工廠接口，直接增加新的工廠類就可以了，創(chuàng)建過程延遲到子類中進行，不需要修改之前的代碼，滿足了開閉原則，達到靈活地生產(chǎn)多種對象。

2、抽象工廠模式
抽象工廠模式是提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。

區(qū)別于工廠方法模式的地方，工廠方法模式是創(chuàng)建一個工廠，可以實現(xiàn)多種對象;而抽象工廠模式是提供一個抽象工廠接口，里面定義多種工廠，每個工廠可以生產(chǎn)多種對象。
前者的重點在于\”怎么生產(chǎn)\”，后者的重點在于\”生產(chǎn)哪些\”;前者是一個抽象產(chǎn)品類，可以派生出多個具體產(chǎn)品類，后者是多個抽象產(chǎn)品類，每個抽象產(chǎn)品類可以派生出多個具體產(chǎn)品類。

3、單例模式
單例模式能保證一個類僅有一個實例，并提供一個訪問它的全局訪問點，同時在類內(nèi)部創(chuàng)造單一對象，通過設(shè)置權(quán)限，使類外部無法再創(chuàng)造對象。單例對象能保證在一個JVM中，該對象只有一個實例存在。

在創(chuàng)建的時候，省去了new操作符，降低了系統(tǒng)內(nèi)存的使用頻率，減輕了系統(tǒng)的壓力。同時單例模式保證在一個jvm中僅存在一個實例的好處就在于好比一個軍隊當(dāng)中只會存在一個***別的軍官來指揮整個軍隊，這樣才能保證獨立控制整個過程，否則如果出現(xiàn)多個，肯定會雜亂無序。
4、建造者模式
建造者模式是將一個復(fù)雜的構(gòu)建與其表示相分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。

在程序當(dāng)中就是將一些不會變的基本組件，通過builder來進行組合，構(gòu)建復(fù)雜對象，實現(xiàn)分離。
這樣做的好處就在于客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié);同時具體的建造者類之間是相互獨立的，對系統(tǒng)的擴展非常有利，滿足開閉原則;由于具體的建造者類是獨立的，因此可以對建造過程逐步細化，而不對其他的模塊產(chǎn)生任何影響。
5、原型模式
原型模式是用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象。

其實就是將對象**了一份并返還給調(diào)用者，對象需繼承Cloneable并重寫clone()方法。原型模式的思想就是將一個對象作為原型，對其進行**、克隆，產(chǎn)生一個和原對象類似的新對象。
分為淺**和深**，前者是將一個對象**后，基本數(shù)據(jù)類型的變量都會重新創(chuàng)建，而引用類型，指向的還是原對象所指向的;后者是將一個對象**后，不論是基本數(shù)據(jù)類型還有引用類型，都是重新創(chuàng)建的。

二、結(jié)構(gòu)型模式：
1、適配器模式
適配器模式是使得原本由于接口不兼容而不能一起工作的那些類可以一起工作，銜接兩個不兼容、獨立的接口的功能，使得它們能夠一起工作，適配器起到中介的作用。
2、裝飾模式
裝飾器模式是動態(tài)地給一個對象添加一些額外的職責(zé)，給一個對象增加一些新的功能，要求裝飾對象和被裝飾對象實現(xiàn)同一個接口，裝飾對象持有被裝飾對象的實例。除了動態(tài)的增加，也可以動態(tài)的撤銷，要做到動態(tài)的形式，不可以用繼承實現(xiàn)，因為繼承是靜態(tài)的。
3、**模式
**模式是為其他對象提供一種**以控制對這個對象的訪問，也就是創(chuàng)建類的**類，間接訪問被**類的過程中，對其功能加以控制。

它和裝飾器模式的區(qū)別在于，裝飾器模式為了增強功能，而**模式是為了加以控制。**模式就是多一個**類出來，替原對象進行一些操作，例如買火車票不一定在火車站買，也可以去代售點。再比如打官司需要請律師，因為律師在法律方面有專長，可以替我們進行操作。
4、外觀模式
外觀模式是為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。

在客戶端和復(fù)雜系統(tǒng)之間再加一層，提供一個容易使用的外觀層。外觀模式是為了解決類與類之家的依賴關(guān)系的，外觀模式就是將他們的關(guān)系放在一個Facade類中，降低了類類之間的耦合度，比如搜狐門戶網(wǎng)站，就利用了外觀模式。
5、橋接模式
橋接模式是將抽象部分與實現(xiàn)部分分離，使它們都可以獨立的變化。橋接模式就是把事物和其具體實現(xiàn)分開，使他們可以各自獨立的變化（突然聯(lián)想到了mvc模式）。

將抽象化與實現(xiàn)化解耦，使得二者可以獨立變化，就好比現(xiàn)在常說的mvc模式，view和model之間通過control來控制，達到高內(nèi)聚低耦合來解耦的目的。
6、組合模式
組合模式是將對象組合成樹形結(jié)構(gòu)以表示\”部分-整體\”的層次結(jié)構(gòu)，組合模式使得用戶對單個對象和組合對象的使用具有一致性。
創(chuàng)建了一個包含自己對象組的類，并提供修改對象組的方法。

在系統(tǒng)的文件和文件夾的問題上就使用了組合模式，文件下不可以有對象，而文件夾下可以有文件對象或者文件夾對象。
7、享元模式
享元模式是運用共享技術(shù)有效地支持大量細粒度的對象。享元模式的主要目的是實現(xiàn)對象的共享，即共享池，當(dāng)系統(tǒng)中對象多的時候可以減少內(nèi)存的開銷，重用現(xiàn)有的同類對象，若未找到匹配的對象，則創(chuàng)建新對象，這樣可以減少對象的創(chuàng)建，降低系統(tǒng)內(nèi)存，提高效率。

三、行為型模式：
1、策略模式
策略模式是定義一系列的算法,把它們一個個封裝起來,并且使它們可相互替換，且算法的變化不會影響到使用算法的客戶。
為了統(tǒng)一接口下的一系列算法類（也就是多種策略），用一個類將其封裝起來，使這些策略可動態(tài)切換。策略模式屬于行為型模式，是為了使這些策略可以相互切換，是為了選擇不同的行為。
2、模版方法模式
模板方法模式是定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。

該模式就是在一個抽象類中，有一個主方法，再定義1…n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過調(diào)用抽象類，實現(xiàn)對子類的調(diào)用。
模板方法使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟，將一些固定步驟、固定邏輯的方法封裝成模板方法。調(diào)用模板方法即可完成那些特定的步驟。

3、觀察者模式
觀察者模式是定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新。
也就是當(dāng)被觀察者狀態(tài)變化時，通知所有觀察者，這種依賴方式具有雙向性，在QQ郵箱中的郵件訂閱和RSS訂閱，當(dāng)用戶瀏覽一些博客時，經(jīng)常會看到RSS圖標(biāo)，簡單來說就是當(dāng)訂閱了該文章，如果后續(xù)有更新，會及時通知用戶。這種現(xiàn)象即是典型的觀察者模式。
4、迭代器模式
迭代器模式是提供一種方法順序訪問一個聚合對象中各個元素,而又無須暴露該對象的內(nèi)部表示。

在Java當(dāng)中，將聚合類中遍歷各個元素的行為分離出來，封裝成迭代器，讓迭代器來處理遍歷的任務(wù);使簡化聚合類，同時又不暴露聚合類的內(nèi)部，在我們經(jīng)常使用的JDK中各個類也都是這些基本的東西。
5、責(zé)任鏈模式
責(zé)任鏈模式是避免請求發(fā)送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。有多個對象，每個對象持有對下一個對象的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一對象決定處理該請求。

但是發(fā)出者并不清楚到底最終那個對象會處理該請求。在生活中學(xué)生進行請假的過程中，會涉及到，學(xué)生請?。