策略模式(對(duì)比工廠模式)
策略模式(對(duì)比工廠模式)
從策略一詞來看, 策略模式是種傾向于行為的模式 .有點(diǎn)類似打仗時(shí)的做戰(zhàn)方案,一般司令員在做戰(zhàn)前都會(huì)根據(jù)實(shí)際情況做百科出幾套不同的方案,如果當(dāng)時(shí)情況有變,就會(huì)根據(jù)相應(yīng)的條件來判定用哪一套方案來替換原定方案。但無論如何替換,替換多少次,仗還是要打的。
策略模式的UML圖 策略(Strategy)模式在結(jié)構(gòu)上與工廠模式類似,**的區(qū)別是工廠模式實(shí)例化一個(gè)產(chǎn)品的操作是在服務(wù)端來做的 ,換句話說客戶端傳達(dá)給服務(wù)端的只是某種標(biāo)識(shí),服務(wù)端根據(jù)該標(biāo)識(shí)實(shí)例化一個(gè)對(duì)象。
而策略模式的客戶端傳達(dá)給服務(wù)端的是一個(gè)實(shí)例,服務(wù)端只是將該實(shí)例拿過去在服務(wù)端的環(huán)境里執(zhí)行該實(shí)例的方法。 工廠模式和策略模式的區(qū)別在于實(shí)例化一個(gè)對(duì)象的位置不同,對(duì)工廠模式而言,實(shí)例化對(duì)象是放在服務(wù)端的,即放在了工廠類里面; 而策略模式實(shí)例化對(duì)象的操作在客戶端,服務(wù)端的“銷售部門”只負(fù)責(zé)傳遞該對(duì)象,并在服務(wù)端的環(huán)境里執(zhí)行特定的操作。 工廠模式要求服務(wù)端的銷售部門足夠靈敏,而策略模式由于對(duì)策略進(jìn)行了封裝,所以他的銷售部門比較傻,需要客戶提供足夠能區(qū)分使用哪種策略的參數(shù),而這**的就是該策略的實(shí)例了。 策略模式的優(yōu)缺點(diǎn) 策略模式的主要優(yōu)點(diǎn)有: 策略模式的缺點(diǎn)主要有兩個(gè): 適用場(chǎng)景 至少在在以下兩種情況下,大家可以考慮使用策略模式, 幾個(gè)類的主要邏輯相同,只在部分邏輯的算法和行為上稍有區(qū)別的情況。
有幾種相似的行為,或者說算法,客戶端需要?jiǎng)討B(tài)地決定使用哪一種,那么可以使用策略模式,將這些算法封裝起來供客戶端調(diào)用。 策略模式是一種簡(jiǎn)單常用的模式,我們?cè)谶M(jìn)行開發(fā)的時(shí)候,會(huì)經(jīng)常有意無意地使用它,一般來說,策略模式不會(huì)單獨(dú)使用,跟模版方法模式、工廠模式等混合使用的情況比較多。
asp.net 的抽象工廠模式和策略模式怎么看都一樣 誰能解釋下嗎!
這2個(gè)區(qū)別比較大吧。策略模式-多個(gè)類繼承一個(gè)抽象類,每個(gè)類都對(duì)這個(gè)抽象類中的方法做了實(shí)現(xiàn)。
這些類都是一種具體的策略。
抽象工廠-多個(gè)類繼承一個(gè)抽象類,每個(gè)類都實(shí)現(xiàn)多個(gè)產(chǎn)品的實(shí)現(xiàn)。打個(gè)比方 番茄炒蛋 燒烤,四川師傅,廣東師傅。 四川師傅可以做四川味的炒蛋和燒烤,廣東師傅可以做廣東味的燒烤和炒蛋。
軟件設(shè)計(jì)模式主要有哪幾種
軟件設(shè)計(jì)模式主要有以下三大類共23種:
一、創(chuàng)建型模式:
1、工廠方法模式
工廠方法模式的創(chuàng)建是因?yàn)楹?jiǎn)單工廠模式有一個(gè)問題,在簡(jiǎn)單工廠模式中類的創(chuàng)建依賴工廠類,如果想要拓展程序,必須對(duì)工廠類進(jìn)行修改,這違背了開閉原則,所以就出現(xiàn)了工廠方法模式,只需要?jiǎng)?chuàng)建一個(gè)工廠接口和多個(gè)工廠實(shí)現(xiàn)類。
子類可以自己決定實(shí)例化哪一個(gè)工廠類,client類針對(duì)抽象接口進(jìn)行編程,如果需要增加新的功能,繼承工廠接口,直接增加新的工廠類就可以了,創(chuàng)建過程延遲到子類中進(jìn)行,不需要修改之前的代碼,滿足了開閉原則,達(dá)到靈活地生產(chǎn)多種對(duì)象。
2、抽象工廠模式
抽象工廠模式是提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口,而無需指定它們具體的類。
區(qū)別于工廠方法模式的地方,工廠方法模式是創(chuàng)建一個(gè)工廠,可以實(shí)現(xiàn)多種對(duì)象;而抽象工廠模式是提供一個(gè)抽象工廠接口,里面定義多種工廠,每個(gè)工廠可以生產(chǎn)多種對(duì)象。
前者的重點(diǎn)在于\”怎么生產(chǎn)\”,后者的重點(diǎn)在于\”生產(chǎn)哪些\”;前者是一個(gè)抽象產(chǎn)品類,可以派生出多個(gè)具體產(chǎn)品類,后者是多個(gè)抽象產(chǎn)品類,每個(gè)抽象產(chǎn)品類可以派生出多個(gè)具體產(chǎn)品類。
3、單例模式
單例模式能保證一個(gè)類僅有一個(gè)實(shí)例,并提供一個(gè)訪問它的全局訪問點(diǎn),同時(shí)在類內(nèi)部創(chuàng)造單一對(duì)象,通過設(shè)置權(quán)限,使類外部無法再創(chuàng)造對(duì)象。單例對(duì)象能保證在一個(gè)JVM中,該對(duì)象只有一個(gè)實(shí)例存在。
在創(chuàng)建的時(shí)候,省去了new操作符,降低了系統(tǒng)內(nèi)存的使用頻率,減輕了系統(tǒng)的壓力。同時(shí)單例模式保證在一個(gè)jvm中僅存在一個(gè)實(shí)例的好處就在于好比一個(gè)軍隊(duì)當(dāng)中只會(huì)存在一個(gè)***別的軍官來指揮整個(gè)軍隊(duì),這樣才能保證獨(dú)立控制整個(gè)過程,否則如果出現(xiàn)多個(gè),肯定會(huì)雜亂無序。
4、建造者模式
建造者模式是將一個(gè)復(fù)雜的構(gòu)建與其表示相分離,使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
在程序當(dāng)中就是將一些不會(huì)變的基本組件,通過builder來進(jìn)行組合,構(gòu)建復(fù)雜對(duì)象,實(shí)現(xiàn)分離。
這樣做的好處就在于客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié);同時(shí)具體的建造者類之間是相互獨(dú)立的,對(duì)系統(tǒng)的擴(kuò)展非常有利,滿足開閉原則;由于具體的建造者類是獨(dú)立的,因此可以對(duì)建造過程逐步細(xì)化,而不對(duì)其他的模塊產(chǎn)生任何影響。
5、原型模式
原型模式是用原型實(shí)例指定創(chuàng)建對(duì)象的種類,并且通過拷貝這些原型創(chuàng)建新的對(duì)象。
其實(shí)就是將對(duì)象**了一份并返還給調(diào)用者,對(duì)象需繼承Cloneable并重寫clone()方法。原型模式的思想就是將一個(gè)對(duì)象作為原型,對(duì)其進(jìn)行**、克隆,產(chǎn)生一個(gè)和原對(duì)象類似的新對(duì)象。
分為淺**和深**,前者是將一個(gè)對(duì)象**后,基本數(shù)據(jù)類型的變量都會(huì)重新創(chuàng)建,而引用類型,指向的還是原對(duì)象所指向的;后者是將一個(gè)對(duì)象**后,不論是基本數(shù)據(jù)類型還有引用類型,都是重新創(chuàng)建的。
二、結(jié)構(gòu)型模式:
1、適配器模式
適配器模式是使得原本由于接口不兼容而不能一起工作的那些類可以一起工作,銜接兩個(gè)不兼容、獨(dú)立的接口的功能,使得它們能夠一起工作,適配器起到中介的作用。
2、裝飾模式
裝飾器模式是動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé),給一個(gè)對(duì)象增加一些新的功能,要求裝飾對(duì)象和被裝飾對(duì)象實(shí)現(xiàn)同一個(gè)接口,裝飾對(duì)象持有被裝飾對(duì)象的實(shí)例。除了動(dòng)態(tài)的增加,也可以動(dòng)態(tài)的撤銷,要做到動(dòng)態(tài)的形式,不可以用繼承實(shí)現(xiàn),因?yàn)槔^承是靜態(tài)的。
3、**模式
**模式是為其他對(duì)象提供一種**以控制對(duì)這個(gè)對(duì)象的訪問,也就是創(chuàng)建類的**類,間接訪問被**類的過程中,對(duì)其功能加以控制。
它和裝飾器模式的區(qū)別在于,裝飾器模式為了增強(qiáng)功能,而**模式是為了加以控制。**模式就是多一個(gè)**類出來,替原對(duì)象進(jìn)行一些操作,例如買火車票不一定在火車站買,也可以去代售點(diǎn)。再比如打官司需要請(qǐng)律師,因?yàn)槁蓭熢诜煞矫嬗袑iL(zhǎng),可以替我們進(jìn)行操作。
4、外觀模式
外觀模式是為子系統(tǒng)中的一組接口提供一個(gè)一致的界面,外觀模式定義了一個(gè)高層接口,這個(gè)接口使得這一子系統(tǒng)更加容易使用。
在客戶端和復(fù)雜系統(tǒng)之間再加一層,提供一個(gè)容易使用的外觀層。外觀模式是為了解決類與類之家的依賴關(guān)系的,外觀模式就是將他們的關(guān)系放在一個(gè)Facade類中,降低了類類之間的耦合度,比如搜狐門戶網(wǎng)站,就利用了外觀模式。
5、橋接模式
橋接模式是將抽象部分與實(shí)現(xiàn)部分分離,使它們都可以獨(dú)立的變化。橋接模式就是把事物和其具體實(shí)現(xiàn)分開,使他們可以各自獨(dú)立的變化(突然聯(lián)想到了mvc模式)。
將抽象化與實(shí)現(xiàn)化解耦,使得二者可以獨(dú)立變化,就好比現(xiàn)在常說的mvc模式,view和model之間通過control來控制,達(dá)到高內(nèi)聚低耦合來解耦的目的。
6、組合模式
組合模式是將對(duì)象組合成樹形結(jié)構(gòu)以表示\”部分-整體\”的層次結(jié)構(gòu),組合模式使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。
創(chuàng)建了一個(gè)包含自己對(duì)象組的類,并提供修改對(duì)象組的方法。
在系統(tǒng)的文件和文件夾的問題上就使用了組合模式,文件下不可以有對(duì)象,而文件夾下可以有文件對(duì)象或者文件夾對(duì)象。
7、享元模式
享元模式是運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。享元模式的主要目的是實(shí)現(xiàn)對(duì)象的共享,即共享池,當(dāng)系統(tǒng)中對(duì)象多的時(shí)候可以減少內(nèi)存的開銷,重用現(xiàn)有的同類對(duì)象,若未找到匹配的對(duì)象,則創(chuàng)建新對(duì)象,這樣可以減少對(duì)象的創(chuàng)建,降低系統(tǒng)內(nèi)存,提高效率。
三、行為型模式:
1、策略模式
策略模式是定義一系列的算法,把它們一個(gè)個(gè)封裝起來,并且使它們可相互替換,且算法的變化不會(huì)影響到使用算法的客戶。
為了統(tǒng)一接口下的一系列算法類(也就是多種策略),用一個(gè)類將其封裝起來,使這些策略可動(dòng)態(tài)切換。策略模式屬于行為型模式,是為了使這些策略可以相互切換,是為了選擇不同的行為。
2、模版方法模式
模板方法模式是定義一個(gè)操作中的算法的骨架,而將一些步驟延遲到子類中。
該模式就是在一個(gè)抽象類中,有一個(gè)主方法,再定義1…n個(gè)方法,可以是抽象的,也可以是實(shí)際的方法,定義一個(gè)類,繼承該抽象類,重寫抽象方法,通過調(diào)用抽象類,實(shí)現(xiàn)對(duì)子類的調(diào)用。
模板方法使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟,將一些固定步驟、固定邏輯的方法封裝成模板方法。調(diào)用模板方法即可完成那些特定的步驟。
3、觀察者模式
觀察者模式是定義對(duì)象間的一種一對(duì)多的依賴關(guān)系,當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí),所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。
也就是當(dāng)被觀察者狀態(tài)變化時(shí),通知所有觀察者,這種依賴方式具有雙向性,在QQ郵箱中的郵件訂閱和RSS訂閱,當(dāng)用戶瀏覽一些博客時(shí),經(jīng)常會(huì)看到RSS圖標(biāo),簡(jiǎn)單來說就是當(dāng)訂閱了該文章,如果后續(xù)有更新,會(huì)及時(shí)通知用戶。這種現(xiàn)象即是典型的觀察者模式。
4、迭代器模式
迭代器模式是提供一種方法順序訪問一個(gè)聚合對(duì)象中各個(gè)元素,而又無須暴露該對(duì)象的內(nèi)部表示。
在Java當(dāng)中,將聚合類中遍歷各個(gè)元素的行為分離出來,封裝成迭代器,讓迭代器來處理遍歷的任務(wù);使簡(jiǎn)化聚合類,同時(shí)又不暴露聚合類的內(nèi)部,在我們經(jīng)常使用的JDK中各個(gè)類也都是這些基本的東西。
5、責(zé)任鏈模式
責(zé)任鏈模式是避免請(qǐng)求發(fā)送者與接收者耦合在一起,讓多個(gè)對(duì)象都有可能接收請(qǐng)求,將這些對(duì)象連接成一條鏈,并且沿著這條鏈傳遞請(qǐng)求,直到有對(duì)象處理它為止。有多個(gè)對(duì)象,每個(gè)對(duì)象持有對(duì)下一個(gè)對(duì)象的引用,這樣就會(huì)形成一條鏈,請(qǐng)求在這條鏈上傳遞,直到某一對(duì)象決定處理該請(qǐng)求。
但是發(fā)出者并不清楚到底最終那個(gè)對(duì)象會(huì)處理該請(qǐng)求。在生活中學(xué)生進(jìn)行請(qǐng)假的過程中,會(huì)涉及到,學(xué)生請(qǐng)?。