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