軟件設(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ì)象的接口，而無(wú)需指定它們具體的類。區(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)限，使類外部無(wú)法再創(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è)*級(jí)別的軍官來(lái)指揮整個(gè)軍隊(duì)，這樣才能保證獨(dú)立控制整個(gè)過程，否則如果出現(xiàn)多個(gè)，肯定會(huì)雜亂無(wú)序。
4、建造者模式
建造者模式是將一個(gè)復(fù)雜的構(gòu)建與其表示相分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。在程序當(dāng)中就是將一些不會(huì)變的基本組件，通過builder來(lái)進(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ì)象復(fù)制了一份并返還給調(diào)用者，對(duì)象需繼承Cloneable并重寫clone()方法。原型模式的思想就是將一個(gè)對(duì)象作為原型，對(duì)其進(jìn)行復(fù)制、克隆，產(chǎn)生一個(gè)和原對(duì)象類似的新對(duì)象。
分為淺復(fù)制和深復(fù)制，前者是將一個(gè)對(duì)象復(fù)制后，基本數(shù)據(jù)類型的變量都會(huì)重新創(chuàng)建，而引用類型，指向的還是原對(duì)象所指向的；后者是將一個(gè)對(duì)象復(fù)制后，不論是基本數(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è)代理類出來(lái)，替原對(duì)象進(jìn)行一些操作，例如買火車票不一定在火車站買，也可以去代售點(diǎn)。再比如打官司需要請(qǐng)律師，因?yàn)槁蓭熢诜煞矫嬗袑ｉL(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來(lái)控制，達(dá)到高內(nèi)聚低耦合來(lá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è)封裝起來(lái),并且使它們可相互替換，且算法的變化不會(huì)影響到使用算法的客戶。
為了統(tǒng)一接口下的一系列算法類（也就是多種策略），用一個(gè)類將其封裝起來(lái)，使這些策略可動(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)單來(lái)說就是當(dāng)訂閱了該文章，如果后續(xù)有更新，會(huì)及時(shí)通知用戶。這種現(xiàn)象即是典型的觀察者模式。
4、迭代器模式
迭代器模式是提供一種方法順序訪問一個(gè)聚合對(duì)象中各個(gè)元素,而又無(wú)須暴露該對(duì)象的內(nèi)部表示。
在Java當(dāng)中，將聚合類中遍歷各個(gè)元素的行為分離出來(lái)，封裝成迭代器，讓迭代器來(lái)處理遍歷的任務(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)假會(huì)一級(jí)一級(jí)往上批，最終處理，具體由誰(shuí)批準(zhǔn)可能不清楚。在程序當(dāng)中，現(xiàn)在使用的struts攔截器即用到了責(zé)任鏈模式。
6、命令模式
命令模式是將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象，從而使發(fā)出者可以用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化。模式當(dāng)中存在調(diào)用者、接收者、命令三個(gè)對(duì)象，實(shí)現(xiàn)請(qǐng)求和執(zhí)行分開；調(diào)用者選擇命令發(fā)布，命令指定接收者。
7、備忘錄模式
備忘錄模式是在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。創(chuàng)建一個(gè)備忘錄類，用來(lái)存儲(chǔ)原始類的信息；同時(shí)創(chuàng)建備忘錄倉(cāng)庫(kù)類，用來(lái)存儲(chǔ)備忘錄類，主要目的是保存一個(gè)對(duì)象的某個(gè)狀態(tài)，以便在適當(dāng)?shù)臅r(shí)候恢復(fù)對(duì)象，也就是做個(gè)備份。
在系統(tǒng)當(dāng)中使用的撤銷操作，即是使用了備忘錄模式，系統(tǒng)可以保存有限次數(shù)的文件狀態(tài)，用戶可以進(jìn)行上幾個(gè)狀態(tài)的恢復(fù)，也就是用到了備忘錄模式。
8、狀態(tài)模式
狀態(tài)模式是允許對(duì)象在內(nèi)部狀態(tài)發(fā)生改變時(shí)改變它的行為。對(duì)象具有多種狀態(tài)，且每種狀態(tài)具有特定的行為。
在網(wǎng)站的積分系統(tǒng)中，用戶具有不同的積分，也就對(duì)應(yīng)了不同的狀態(tài)；還有QQ的用戶狀態(tài)有幾種狀態(tài)，在線、隱身、忙碌等，每個(gè)狀態(tài)對(duì)應(yīng)不同的操作，而且你的好友也能看到你的狀態(tài)。
9、訪問者模式
訪問者模式主要是將數(shù)據(jù)結(jié)構(gòu)與數(shù)據(jù)操作分離。在被訪問的類里面加一個(gè)對(duì)外提供接待訪問者的接口，訪問者封裝了對(duì)被訪問者結(jié)構(gòu)的一些雜亂操作，解耦結(jié)構(gòu)與算法，同時(shí)具有優(yōu)秀的擴(kuò)展性。通俗來(lái)講就是一種分離對(duì)象數(shù)據(jù)結(jié)構(gòu)與行為的方法。
通過這種分離，可達(dá)到為一個(gè)被訪問者動(dòng)態(tài)添加新的操作而無(wú)需做其它的修改的效果。訪問者模式的優(yōu)點(diǎn)是增加操作很容易，因?yàn)樵黾硬僮饕馕吨黾有碌脑L問者。訪問者模式將有關(guān)行為集中到一個(gè)訪問者對(duì)象中，其改變不影響系統(tǒng)數(shù)據(jù)結(jié)構(gòu)。
10、中介者模式
中介者模式是用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互，中介者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。
例如，MVC模式中control就是model和view的中介者。與適配器區(qū)別在于，適配器是為了兼容不同的接口，而中介者是為了將顯示和操作分離。
11、解釋器模式
解釋器模式是給定一個(gè)語(yǔ)言，定義它的文法表示，并定義一個(gè)解釋器，這個(gè)解釋器使用該標(biāo)識(shí)來(lái)解釋語(yǔ)言中的句子，基本也就用在這個(gè)范圍內(nèi)，適用面較窄，例如：正則表達(dá)式的解釋等。
參考資料來(lái)源：百度百科-軟件設(shè)計(jì)模式
軟件設(shè)計(jì)模式有哪些?
問題一：軟件設(shè)計(jì)模式主要有哪幾種 創(chuàng)建型模式用來(lái)處理對(duì)象的創(chuàng)建過程，主要包含以下5種設(shè)計(jì)模式：
? 工廠方法模式（Factory Method Pattern）
? 抽象工廠模式（Abstract Factory Pattern）
? 建造者模式（Builder Pattern）
? 原型模式（Prototype Pattern）
? 單例模式（Singleton Pattern）
結(jié)構(gòu)型模式用來(lái)處理類或者對(duì)象的組合，主要包含以下7種設(shè)計(jì)模式：
? 適配器模式（Adapter Pattern）
? 橋接模式（Bridge Pattern）
? 組合模式（posite Pattern）
? 裝飾者模式（Decorator Pattern）
? 外觀模式（Facade Pattern）
? 享元模式（Flyweight Pattern）
? 代理模式（Proxy Pattern）
行為型模式用來(lái)對(duì)類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述，主要包含以下11種設(shè)計(jì)模式：
? 責(zé)任鏈模式（Chain of Pattern）
? 命令模式（mand Pattern）
? 解釋器模式（ Pattern）
? 迭代器模式（Iterator Pattern）
? 中介者模式（Mediator Pattern）
? 備忘錄模式（Memento Pattern）
? 觀察者模式（Observer Pattern）
? 狀態(tài)模式（State Pattern）
? 策略模式（Strategy Pattern）
? 模板方法模式（Template Method Pattern）
? 訪問者模式（Visitor Pattern）
問題二：軟件開發(fā)的設(shè)計(jì)模式有哪些 最常用的是設(shè)計(jì)模式是工廠模式或者單例模式。
問題三：什么是軟件設(shè)計(jì)模式 你好。
軟件設(shè)計(jì)模式就是Uml統(tǒng)一建模語(yǔ)言的技巧性概念。主要研究各個(gè)類模塊和接口之間的安排與搭配，也是為程序員提供亥流的一個(gè)很好的平臺(tái)。
利用軟件設(shè)計(jì)模式您可以做出質(zhì)量更高，代碼更少，擴(kuò)充更容易的軟件。我個(gè)人理解它更像是一個(gè)工具箱，可以讓你生產(chǎn)出更漂亮、更簡(jiǎn)潔的代碼。
我的回答您還滿意嗎？
問題四：常見的軟件開發(fā)模式和設(shè)計(jì)模式有哪些 MVC
這個(gè)是JAVA ee中就經(jīng)常用到的模式
將數(shù)據(jù)模型、界面視圖和業(yè)務(wù)邏輯控制分開的模式在Android開發(fā)中體現(xiàn)的最明顯
數(shù)據(jù)模型一定單獨(dú)
界面視圖在布局中實(shí)現(xiàn)
業(yè)務(wù)控制單獨(dú)編寫，典型的MVC
問題五：軟件工程中的設(shè)計(jì)模式都有哪些 Builder模式：比如.Builder。
適配器模式：比如GridView、ListView與Adapter。
命令模式：比如Handler.post。
享元模式：比如Message.obtain。
單例模式：比如.。
觀察者模式：比如。
這是一些經(jīng)常用到的設(shè)計(jì)模式以及舉例。
問題六：列出幾種軟件開發(fā)中常見的設(shè)計(jì)模式并解釋 設(shè)計(jì)模式主要分三個(gè)類型:創(chuàng)建型、結(jié)構(gòu)型和行為型。
其中創(chuàng)建型有：
一、Singleton，單例模式：保證一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)
二、Abstract Factory，抽象工廠：提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無(wú)須指定它們的具體類。
三、Factory Method，工廠方法：定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類，F(xiàn)actory Method使一個(gè)類的實(shí)例化延遲到了子類。
四、Builder，建造模式：將一個(gè)復(fù)雜對(duì)象的構(gòu)建與他的表示相分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
五、Prototype，原型模式：用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過拷貝這些原型來(lái)創(chuàng)建新的對(duì)象。
行為型有：
六、Iterator，迭代器模式：提供一個(gè)方法順序訪問一個(gè)聚合對(duì)象的各個(gè)元素，而又不需要暴露該對(duì)象的內(nèi)部表示。
七、Observer，觀察者模式：定義對(duì)象間一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知自動(dòng)更新。
八、Template Method，模板方法：定義一個(gè)操作中的算法的骨架，而將一些步驟延遲到子類中，使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可以重定義該算法得某些特定步驟。
九、mand，命令模式：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可以用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化，對(duì)請(qǐng)求排隊(duì)和記錄請(qǐng)求日志，以及支持可撤銷的操作。
十、State，狀態(tài)模式：允許對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變他的行為。對(duì)象看起來(lái)似乎改變了他的類。
十一、Strategy，策略模式：定義一系列的算法，把他們一個(gè)個(gè)封裝起來(lái)，并使他們可以互相替換，本模式使得算法可以獨(dú)立于使用它們的客戶。
十二、China of ，職責(zé)鏈模式：使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免請(qǐng)求的送發(fā)者和接收者之間的耦合關(guān)系
十三、Mediator，中介者模式：用一個(gè)中介對(duì)象封裝一些列的對(duì)象交互。
十四、Visitor，訪問者模式：表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用于這個(gè)元素的新操作。
十五、，解釋器模式：給定一個(gè)語(yǔ)言，定義他的文法的一個(gè)表示，并定義一個(gè)解釋器，這個(gè)解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。
十六、Memento，備忘錄模式：在不破壞對(duì)象的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。
結(jié)構(gòu)型有：
十七、posite，組合模式：將對(duì)象組合成樹形結(jié)構(gòu)以表示部分整體的關(guān)系，posite使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。
十八、Facade，外觀模式：為子系統(tǒng)中的一組接口提供一致的界面，fa?ade提供了一高層接口，這個(gè)接口使得子系統(tǒng)更容易使用。
十九、Proxy，代理模式：為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問
二十、Adapter,適配器模式：將一類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些類可以一起工作。
二十一、Decrator，裝飾頂式：動(dòng)態(tài)地給一個(gè)對(duì)象增加一些額外的職責(zé)，就增加的功能來(lái)說，Decorator模式相比生成子類更加靈活。......>>
問題七：設(shè)計(jì)模式都有哪些? 設(shè)計(jì)模式主要分三個(gè)類型:創(chuàng)建型、結(jié)構(gòu)型和行為型。
其中創(chuàng)建型有：
一、Singleton，單例模式：保證一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)
二、Abstract Factory，抽象工廠：提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無(wú)須指定它們的具體類。
三、Factory Method，工廠方法：定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類，F(xiàn)actory Method使一個(gè)類的實(shí)例化延遲到了子類。
四、Builder，建造模式：將一個(gè)復(fù)雜對(duì)象的構(gòu)建與他的表示相分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
五、Prototype，原型模式：用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過拷貝這些原型來(lái)創(chuàng)建新的對(duì)象。
行為型有：
六、Iterator，迭代器模式：提供一個(gè)方法順序訪問一個(gè)聚合對(duì)象的各個(gè)元素，而又不需要暴露該對(duì)象的內(nèi)部表示。
七、Observer，觀察者模式：定義對(duì)象間一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知自動(dòng)更新。
八、Template Method，模板方法：定義一個(gè)操作中的算法的骨架，而將一些步驟延遲到子類中，使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可以重定義該算法得某些特定步驟。
九、mand，命令模式：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可以用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化，對(duì)請(qǐng)求排隊(duì)和記錄請(qǐng)求日志，以及支持可撤銷的操作。
十、State，狀態(tài)模式：允許對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變他的行為。對(duì)象看起來(lái)似乎改變了他的類。
十一、Strategy，策略模式：定義一系列的算法，把他們一個(gè)個(gè)封裝起來(lái)，并使他們可以互相替換，本模式使得算法可以獨(dú)立于使用它們的客戶。
十二、China of ，職責(zé)鏈模式：使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免請(qǐng)求的送發(fā)者和接收者之間的耦合關(guān)系
十三、Mediator，中介者模式：用一個(gè)中介對(duì)象封裝一些列的對(duì)象交互。
十四、Visitor，訪問者模式：表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用于這個(gè)元素的新操作。
十五、，解釋器模式：給定一個(gè)語(yǔ)言，定義他的文法的一個(gè)表示，并定義一個(gè)解釋器，這個(gè)解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。
十六、Memento，備忘錄模式：在不破壞對(duì)象的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。
結(jié)構(gòu)型有：
十七、posite，組合模式：將對(duì)象組合成樹形結(jié)構(gòu)以表示部分整體的關(guān)系，posite使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。
十八、Facade，外觀模式：為子系統(tǒng)中的一組接口提供一致的界面，fa?ade提供了一高層接口，這個(gè)接口使得子系統(tǒng)更容易使用。
十九、Proxy，代理模式：為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問
二十、Adapter,適配器模式：將一類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些類可以一起工作。
二十一、Decrator，裝飾模式：動(dòng)態(tài)地給一個(gè)對(duì)象增加一些額外的職責(zé)，就增加的功能來(lái)說，Decorator模式相比生成子類更加靈活。
二十二、Bridge，橋模式：將抽......>>
問題八：總共有幾種設(shè)計(jì)模式？？？ 共有23種
簡(jiǎn)單工廠是設(shè)計(jì)模式中比較簡(jiǎn)單的創(chuàng)建型模式
其原理就是創(chuàng)建一個(gè)工廠類（接口），客戶端調(diào)用的為接口的實(shí)現(xiàn)類，來(lái)實(shí)現(xiàn)代碼的復(fù)用與簡(jiǎn)單恭耦，其實(shí)簡(jiǎn)單工廠也是工廠方法模式的一種特殊實(shí)現(xiàn)。
推薦你看篇文章，你就會(huì)更好的理解。
blog.csdn/ai92/article/details/209198
問題九：軟件設(shè)計(jì)模式的四個(gè)要素 設(shè)計(jì)模式使人們可以更加簡(jiǎn)單方便地復(fù)用成功的設(shè)計(jì)和體系結(jié)構(gòu)。將已證實(shí)的技術(shù)表述成設(shè)計(jì)模式也會(huì)使新系統(tǒng)開發(fā)者更加容易理解其設(shè)計(jì)思路。模式名稱一個(gè)助記名，它用一兩個(gè)詞來(lái)描述模式的問題、解決方案和效果。命名一個(gè)新的模式增加了我們的設(shè)計(jì)詞匯。設(shè)計(jì)模式允許我們?cè)谳^高的抽象層次上進(jìn)行設(shè)計(jì)?；谝粋€(gè)模式詞匯表，我們自己以及同事之間就可以討論模式并在編寫文檔時(shí)使用它們。模式名可以幫助我們思考，便于我們與其他人交流設(shè)計(jì)思想及設(shè)計(jì)結(jié)果。找到恰當(dāng)?shù)哪Ｊ矫彩俏覀冊(cè)O(shè)計(jì)模式編目工作的難點(diǎn)之一。問題描述問題存在的前因后果，它可能描述了特定的設(shè)計(jì)問題，如怎樣用對(duì)象表示算法等。也可能描述了導(dǎo)致不靈活設(shè)計(jì)的類或?qū)ο蠼Y(jié)構(gòu)。有時(shí)候，問題部分會(huì)包括使用模式必須滿足的一系列先決條件。解決方案描述了設(shè)計(jì)的組成成分，它們之間的相互關(guān)系及各自的職責(zé)和協(xié)作方式。因?yàn)槟Ｊ骄拖褚粋€(gè)模板，可應(yīng)用于多種不同場(chǎng)合，所以解決方案并不描述一個(gè)特定而具體的設(shè)計(jì)或?qū)崿F(xiàn)，而是提供設(shè)計(jì)問題的抽象描述和怎樣用一個(gè)具有一般意義的元素組合（類或?qū)ο蠼M合）來(lái)解決這個(gè)問題。效果描述了模式應(yīng)用的效果及使用模式應(yīng)權(quán)衡的問題。盡管我們描述設(shè)計(jì)決策時(shí)，并不總提到模式效果，但它們對(duì)于評(píng)價(jià)設(shè)計(jì)選擇和理解使用模式的代價(jià)及好處具有重要意義。軟件效果大多關(guān)注對(duì)時(shí)間和空間的衡量，它們也表述了語(yǔ)言和實(shí)現(xiàn)問題。因?yàn)閺?fù)用是面向?qū)ο笤O(shè)計(jì)的要素之一，所以模式效果包括它對(duì)系統(tǒng)的靈活性、擴(kuò)充性或可移植性的影響，顯式地列出這些效果對(duì)理解和評(píng)價(jià)這些模式很有幫助。
問題十：有哪些比較好的設(shè)計(jì)模式 單例模式：這個(gè)是必須會(huì)的
觀察者模式：這個(gè)最典型的應(yīng)用就是mvc模式。
flyweight模式：這個(gè)也很常用
posite（組合）：這個(gè)很常見吧，
適配器模式：這個(gè)也很常用，比如我們一般會(huì)封裝一些類庫(kù)。然后成為我們用起來(lái)更方便的類。
其它的還很多的。總共23種。設(shè)計(jì)模式需要邊學(xué)邊用。很多不好理解。等以后覺得自己設(shè)計(jì)思路不太好了可以再翻翻。
軟件的開發(fā)模式有哪些？
??1.瀑布模型 ： 1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是*被廣泛采用的軟件開發(fā)模型。
2.迭代模型 ： 在某種程度上，開發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：需求、分析設(shè)計(jì)、實(shí)施和測(cè)試工作流程。實(shí)質(zhì)上，它類似小型的瀑布式項(xiàng)目。RUP認(rèn)為，所有的階段都可以細(xì)分為迭代。每一次的迭代都會(huì)產(chǎn)生一個(gè)可以發(fā)布的產(chǎn)品，這個(gè)產(chǎn)品是最終產(chǎn)品的一個(gè)子集。
3.敏捷開發(fā)模型 ： 是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開發(fā)能力。相對(duì)于“非敏捷”，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對(duì)面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本。能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重軟件開發(fā)中人的作用。敏捷建模（Agile Modeling，AM）的價(jià)值觀包括了XP的四個(gè)價(jià)值觀：溝通、簡(jiǎn)單、反饋、勇氣，此外，還擴(kuò)展了第五個(gè)價(jià)值觀：謙遜。
4.螺旋模型：螺旋模型是一種演化軟件開發(fā)過程模型，它兼顧了快速原型的迭代的特征以及瀑布模型的系統(tǒng)化與嚴(yán)格監(jiān)控。螺旋模型*的特點(diǎn)在于引入了其他模型不具備的風(fēng)險(xiǎn)分析，使軟件在無(wú)法排除重大風(fēng)險(xiǎn)時(shí)有機(jī)會(huì)停止，以減小損失。同時(shí)，在每個(gè)迭代階段構(gòu)建原型是螺旋模型用以減小風(fēng)險(xiǎn)的途徑。螺旋模型更適合大型的昂貴的系統(tǒng)級(jí)的軟件應(yīng)用。
5.快速原型模型：快速原型模型需要迅速建造一個(gè)可以運(yùn)行的軟件原型 ，以便理解和澄清問題，使開發(fā)人員與用戶達(dá)成共識(shí)，最終在確定的客戶需求基礎(chǔ)上開發(fā)客戶滿意的軟件產(chǎn)品。 快速原型模型允許在需求分析階段對(duì)軟件的需求進(jìn)行初步而非完全的分析和定義，快速設(shè)計(jì)開發(fā)出軟件系統(tǒng)的原型，該原型向用戶展示待開發(fā)軟件的全部或部分功能和性能；用戶對(duì)該原型進(jìn)行測(cè)試評(píng)定，給出具體改進(jìn)意見以豐富細(xì)化軟件需求；開發(fā)人員據(jù)此對(duì)軟件進(jìn)行修改完善，直至用戶滿意認(rèn)可之后，進(jìn)行軟件的完整實(shí)現(xiàn)及測(cè)試、維護(hù)。
在做軟件開發(fā)的時(shí)候會(huì)經(jīng)常用到哪些設(shè)計(jì)模式，，，，，，
引用《軟件秘笈-設(shè)計(jì)模式那點(diǎn)事》書籍：
按照目的來(lái)分，設(shè)計(jì)模式可以分為創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式。
創(chuàng)建型模式用來(lái)處理對(duì)象的創(chuàng)建過程；結(jié)構(gòu)型模式用來(lái)處理類或者對(duì)象的組合；行為型模式用來(lái)對(duì)類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述。
創(chuàng)建型模式用來(lái)處理對(duì)象的創(chuàng)建過程，主要包含以下5種設(shè)計(jì)模式：
? 工廠方法模式（Factory Method Pattern）
? 抽象工廠模式（Abstract Factory Pattern）
? 建造者模式（Builder Pattern）
? 原型模式（Prototype Pattern）
? 單例模式（Singleton Pattern）
結(jié)構(gòu)型模式用來(lái)處理類或者對(duì)象的組合，主要包含以下7種設(shè)計(jì)模式：
? 適配器模式（Adapter Pattern）
? 橋接模式（Bridge Pattern）
? 組合模式（Composite Pattern）
? 裝飾者模式（Decorator Pattern）
? 外觀模式（Facade Pattern）
? 享元模式（Flyweight Pattern）
? 代理模式（Proxy Pattern）
行為型模式用來(lái)對(duì)類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述，主要包含以下11種設(shè)計(jì)模式：
? 責(zé)任鏈模式（Chain of Pattern）
? 命令模式（Command Pattern）
? 解釋器模式（ Pattern）
? 迭代器模式（Iterator Pattern）
? 中介者模式（Mediator Pattern）
? 備忘錄模式（Memento Pattern）
? 觀察者模式（Observer Pattern）
? 狀態(tài)模式（State Pattern）
? 策略模式（Strategy Pattern）
? 模板方法模式（Template Method Pattern）
? 訪問者模式（Visitor Pattern）
推薦《軟件秘笈：設(shè)計(jì)模式那點(diǎn)事》，看了收獲很大！
軟件開發(fā)模式有哪些？
軟件開發(fā)模式有哪些?快速原型模型：（需要迅速造一個(gè)可以運(yùn)行的軟件原型，以便理解和澄清問題）快速原型模型允許在需求分析階段對(duì)軟件的需求進(jìn)行初步的非完全的分析和定義，快速設(shè)計(jì)開發(fā)出軟件系統(tǒng)的原型（展示待開發(fā)軟件的全部或部分功能和性能
（過程：用戶對(duì)該原型進(jìn)行測(cè)試評(píng)定，給出具體改善的意見以及豐富的細(xì)化軟件需求，開發(fā)人員進(jìn)行修改完善）優(yōu)點(diǎn)：
克服瀑布模型的缺點(diǎn)，減少由于軟件需求不明確帶來(lái)的開發(fā)風(fēng)險(xiǎn)
缺點(diǎn)：
A、 所選用的開發(fā)技術(shù)和工具不一定符合主流的發(fā)展
B、 快速建立起來(lái)的系統(tǒng)加上連續(xù)的修改可能會(huì)造成 產(chǎn)品質(zhì)量底下增量模型：（采用隨著日程時(shí)間的進(jìn)展而交錯(cuò)的線性序列，每一個(gè)線性徐磊產(chǎn)生軟件的一個(gè)可發(fā)布的“增量”，*個(gè)增量往往就是核心的產(chǎn)品）與其他模型共同之處：它與原型實(shí)現(xiàn)模型和其他演化方法一樣，本質(zhì)都是迭代與原型實(shí)現(xiàn)模型不同之處：它強(qiáng)調(diào)每一個(gè)增量均發(fā)布一個(gè)可操作產(chǎn)品，（它不需要等到所有需求都出來(lái)，只要摸個(gè)需求的增量包出來(lái)即可進(jìn)行開發(fā)）優(yōu)點(diǎn)：
1、 人員分配靈活，一開始不需要投入大量人力資源
2、 當(dāng)配備人員不能在限定的時(shí)間內(nèi)完成產(chǎn)品時(shí)，它可以提供一種先推出核心產(chǎn)品的途徑，可現(xiàn)發(fā)布部分功能給用戶（對(duì)用戶起鎮(zhèn)靜作用）
3、 增量能夠有計(jì)劃的管理技術(shù)風(fēng)險(xiǎn)缺點(diǎn)：
1、 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統(tǒng)分析注：
這種模型將功能細(xì)化后分別開發(fā)的方法較適應(yīng)于需求經(jīng)常改變的軟件開發(fā)過程
原型模型：（樣品模型，采用逐步求精的方法完善原型）主要思想：
先借用已有系統(tǒng)作為原型模型，通過“樣品”不斷改進(jìn)，使得*的產(chǎn)品就是用戶所需要的。原型模型通過向用戶提供原型獲取用戶的反饋，使開發(fā)出的軟件能夠真正反映用戶的需求，采用方法：
原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發(fā)，避免了像瀑布模型一樣在冗長(zhǎng)的開發(fā)過程中難以對(duì)用戶的反饋?zhàn)鞒隹焖俚捻憫?yīng)優(yōu)點(diǎn)： (1）開發(fā)人員和用戶在“原型”上達(dá)成一致。這樣一來(lái)，可以減少設(shè)計(jì)中的錯(cuò)誤和開發(fā)中的風(fēng)險(xiǎn)，也減少了對(duì)用戶培訓(xùn)的時(shí)間，而提高了系統(tǒng)的實(shí)用、正確性以及用戶的滿意程度。 （2）縮短了開發(fā)周期，加快了工程進(jìn)度。
（3）降低成本。
缺點(diǎn)：
1、當(dāng)重新生產(chǎn)該產(chǎn)品時(shí)，難以讓用戶接收，給工程繼續(xù)開展帶來(lái)不利因素。
2、不宜利用原型系統(tǒng)作為最終產(chǎn)品。采用原型模型開發(fā)系統(tǒng)，用戶和開發(fā)者必須達(dá)成一致：
噴泉模型：（以用戶需求為動(dòng)力，以對(duì)象為驅(qū)動(dòng)的模型，主要用于采用對(duì)象技術(shù)的軟件開發(fā)項(xiàng)目）它認(rèn)為軟件開發(fā)過程自下而上周期的各階段是相互迭代和無(wú)間隙的特性
相互迭代：軟件的摸個(gè)部分常常被重復(fù)工作多次，相關(guān)對(duì)象在每次迭代中隨之加入漸進(jìn)的軟件成分
無(wú)間隙:它在各項(xiàng)活動(dòng)之間沒有明顯邊界（如分析和設(shè)計(jì)活動(dòng)之間<由于對(duì)象概念的應(yīng)用，表達(dá)分析，設(shè)計(jì)，實(shí)現(xiàn)等活動(dòng)只用對(duì)象類和關(guān)系>）優(yōu)點(diǎn)：
1、 可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程不便之處：
1、由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。
2、這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的情況螺旋模型：（適合用于需求經(jīng)常變化的項(xiàng)目<適合于大型復(fù)雜的系統(tǒng)>）它主要是風(fēng)險(xiǎn)分析與評(píng)估，沿著螺線進(jìn)行若干次迭代，
過程：
1、 制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件
2、 風(fēng)險(xiǎn)分析：分析評(píng)估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)
3、 實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證；
4、 客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。優(yōu)點(diǎn)：
1、 它由風(fēng)險(xiǎn)驅(qū)動(dòng)，強(qiáng)調(diào)可選方案和約束條件從而支持軟件的重用，有助于將軟件質(zhì)量作為特殊目標(biāo)融入產(chǎn)品開發(fā)中
缺點(diǎn)：
1、 難以讓用戶確信這種煙花方法的結(jié)果是可以控制的
2、 建設(shè)周期長(zhǎng)（而軟件技術(shù)發(fā)展比較快，所以經(jīng)常會(huì)出現(xiàn)軟件開發(fā)完畢后，和當(dāng)前的技術(shù)水平有很大的差距，無(wú)法滿足當(dāng)前用戶的需求）
3、 除非軟件開發(fā)人員擅長(zhǎng)尋找可能的風(fēng)險(xiǎn)，準(zhǔn)確的分析風(fēng)險(xiǎn)，否則將會(huì)帶來(lái)更大的風(fēng)險(xiǎn)瀑布模型：（從本質(zhì)來(lái)講，瀑布模型是一個(gè)軟件開發(fā)架構(gòu),重復(fù)應(yīng)用）
（核心思想：按工序?qū)栴}化簡(jiǎn)，將功能的實(shí)現(xiàn)與設(shè)計(jì)分開，便于分工協(xié)作，采用結(jié)構(gòu)化的分析與設(shè)計(jì)方法將邏輯實(shí)現(xiàn)與物理實(shí)現(xiàn)分開，依照軟件生命周期自上而下，相互銜接的次序<如同瀑布流水逐級(jí)下落>）缺點(diǎn)：
1、 在項(xiàng)目各個(gè)階段之間極少有反饋，各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，增加了工作量
2、 用戶只有在項(xiàng)目生命周期的后期才能看到結(jié)果，增加了開發(fā)的風(fēng)險(xiǎn)
3、 需要過多的強(qiáng)制完成日期和里程碑來(lái)跟蹤各個(gè)項(xiàng)目的階段
4、 在每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋
（如果有信息未被覆蓋或是發(fā)現(xiàn)問題了，必須返回到上一個(gè)階段<甚至更前面的活動(dòng)>并進(jìn)行適當(dāng)?shù)男薷?只有當(dāng)上一階段都被確認(rèn)后才進(jìn)行下一階段）
5、 早期的錯(cuò)誤可能要等到開發(fā)后期的測(cè)試階段才能發(fā)現(xiàn)，進(jìn)而帶來(lái)嚴(yán)重的后果優(yōu)點(diǎn)：
1、 為項(xiàng)目提供了按階段分的檢查點(diǎn)
2、 當(dāng)完成一個(gè)階段后，只需要去關(guān)注后續(xù)階段
3、 可在迭代模型中應(yīng)用瀑布模型按照瀑布模型的階段劃分，軟件測(cè)試可以分為單元測(cè)試，集成測(cè)試，系統(tǒng)測(cè)試
注：由于每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋，對(duì)于經(jīng)常變化的項(xiàng)目而言，瀑布模型毫無(wú)價(jià)值，這種模型的線性過程太理想化，已不適合現(xiàn)代的軟件開發(fā)模式
軟件設(shè)計(jì)模式有哪些
設(shè)計(jì)模式列表基礎(chǔ)模式
委托模式
接口模式
代理模式
創(chuàng)建型模式
抽象工廠模式 (Abstract Factory) ,提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無(wú)需指定它們具體的類。
生成器模式 (Builder)，將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
工廠方法模式 (Factory Methord) ，定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定將哪一個(gè)類實(shí)例化。Factory Method使一個(gè)類的實(shí)例化延遲到其子類。
原型模式 (Prototype) ，用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過拷貝這個(gè)原型來(lái)創(chuàng)建新的對(duì)象。
單例模式 (Singleton)，保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。
結(jié)構(gòu)型模式
適配器模式 (Adapter) ，將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
橋接模式 (Bridge) ，將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。
組合模式 (Composite) ，將對(duì)象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。它使得客戶對(duì)單個(gè)對(duì)象和復(fù)合對(duì)象的使用具有一致性。
容器模式
修飾模式 (Decorator) ，動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就擴(kuò)展功能而言， 它比生成子類方式更為靈活。
擴(kuò)展性模式
外觀模式
享元模式
管道與過濾器模式
代理模式 (Proxy) ，為其他對(duì)象提供一個(gè)代理以控制對(duì)這個(gè)對(duì)象的訪問。
行為模式
責(zé)任鏈模式 (Chain of ) ，為解除請(qǐng)求的發(fā)送者和接收者之間耦合，而使多個(gè)對(duì)象都有機(jī)會(huì)處理這個(gè)請(qǐng)求。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，直到有一個(gè)對(duì)象處理它。
命令模式 (Command) ，將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可取消的操作。
柯里化模式
事件監(jiān)聽器模式
解釋器模式
迭代器模式
中介者模式
備忘錄模式 (Memento) ，在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可將該對(duì)象恢復(fù)到保存的狀態(tài)。
觀察者模式 (Observer) ，定義對(duì)象間的一種一對(duì)多的依賴關(guān)系,以便當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí),所有依賴于它的對(duì)象都得到通知并自動(dòng)刷新。
狀態(tài)模式 (State) ，允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來(lái)似乎修改了它所屬的類。
策略模式 (Strategy) ，定義一系列的算法,把它們一個(gè)個(gè)封裝起來(lái), 并且使它們可相互替換。本模式使得算法的變化可獨(dú)立于使用它的客戶。
模板方法模式
訪問者模式 (Visitor)，表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
層次訪問者模式
并發(fā)模式
模式 Action at a distance
模式 Balking
模式 Guarded
模式 Scheduler
模式 Read write lock
模式 Double checked locking
模式 Disable job requests while running job
實(shí)時(shí)模式
模式 Scheduled task
模式 User interface
模式 Disable job requests while running job
其他
模型—視圖—控制器模式
