第一篇：C#設計模式(23種設計模式)

C#設計模式(23種設計模式)

創建型：

1.單件模式(Singleton Pattern)

2.抽象工廠（Abstract Factory）

3.建造者模式(Builder)

4.工廠方法模式（Factory Method)

5.原型模式(Prototype)

結構型：

6.適配器模式（Adapter Pattern)

7.橋接模式（Bridge Pattern)

8.裝飾模式(Decorator Pattern)

9.組合模式(Composite Pattern)

10.外觀模式（Facade Pattern)

11.享元模式(Flyweight Pattern)

12.代理模式(Proxy Pattern)

13.模板方法(Template Method)

14.命令模式(Command Pattern)

15.迭代器模式(Iterator Pattern)

行為型：

16.觀察者模式(Observer Pattern）

17.解釋器模式(Interpreter Pattern)

18.中介者模式(Mediator Pattern)

19.職責鏈模式(Chain of Responsibility Pattern)

20.備忘錄模式(Memento Pattern)

21.策略模式(Strategy Pattern)

22.訪問者模式(Visitor Pattern)

23.狀態模式(State Pattern)

@Authorkwming

第二篇：Java23種設計模式6大原則總結

設計模式概念：一套被反復使用、多數人知曉、經過分類編目的優秀代碼設計經驗的總結。設計模式要素：模式名稱、問題、舉例、末態環境、推理、其他有關模式、已知的應用。設計模式分類：創建型、結構型、行為型。

創建型模式功能：1.統所使用的具體類的信息封裝起來；

2.類的實例是如何被創建和組織的。

創建型模式作用：1.封裝創建邏輯，不僅僅是new一個對象那么簡單。

2.封裝創建邏輯變化，客戶代碼盡量不修改，或盡量少修改。

常見的創建型模式：單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式。常見的結構型模式：代理模式、裝飾模式、適配器模式、組合模式、橋梁模式、外觀模式、享元模式。

常見行為型模式：模板方法模式、命令模式、責任鏈模式、策略模式、迭代器模式、中介者模式、觀察者模式、備忘錄模式、訪問者模式、狀態模式、解釋器模式。

單一職責原則：一個類應該只有一個職責。

優點：降低類的復雜性；提高類的可讀性；提高代碼的可維護性和復用性；降低因變更引起的風險。

里氏替換原則：

優點：代碼共享，減少創建類的工作量，每個子類都擁有父類的方法和屬性；提高代碼的可重用性；提高代碼的可擴展性；提高產品或項目的開放性。

缺點：1.繼承是入侵式的。只要繼承，就必須擁有父類所有屬性和方法。

2.降低代碼的靈活性。子類必須擁有父類的屬性和方法，使子類收到限制。

3.增強了耦合性。當父類的常量、變量和方法修改時，必須考慮子類的修改，這種修改可能造成大片的代碼需要重構。

依賴倒置原則：高層模塊不應該依賴低層模塊，兩者都依賴其抽象；抽象不依賴細節；細節應該依賴于抽象。

在Java中的表現：模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關系，其依賴關系是通過接口或抽象類產生的；接口或抽象類不依賴于是實現類；實現類依賴于接口或抽象類。

接口隔離原則：1.一個類對另外一個類的依賴性應當是建立在最小的接口上的 2.一個接口代表一個角色，不應當將不同的角色交給一個接口。3.不應該強迫客戶使用它們的不同方法。

如圖所示的電子商務系統在三個地方會使用到訂單類：一個是門戶，只能有查詢方法；一個是外部系統，有添加訂單的方法；一個是管理后臺，添加、刪除、修改、查詢都要用到。“原子”在實踐中的衡量規則：

1.一個接口只對一個子模塊或者業務邏輯進行分類。2.只保留接口中業務邏輯需要的public方法。

3.盡量修改污染了的接口，若修改的風險較大，則可采用適配器模式進行轉化處理。4.接口設計應因項目而異，因環境而異，不能照搬教條。迪米特法則：（表述）只與你直接的朋友們通信；不要跟“陌生人”說話；每一個軟件單位對其他的單位都只有最少的了解，這些了解僅局限于那些與本單位密切相關的軟件單位。

對迪米特法則進行模式設計有兩個：外觀模式、中介者模式。開閉原則：一個軟件實體應當對擴展開放，對修改關閉。

重要性體現：提高復用性；提高維護性；提高靈活性；易于測試 單例模式：單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例單例模式。

優點：1.在內存中只有一個實例，減少了內存的開支。2.只生成一個實例，減少了系統的性能開銷。3.避免對資源的多重占用。

4.可以在系統設置全局的訪問點，優化和共享資源訪問。缺點：1.無法創建子類，擴展困難，若要擴展，除修改代碼基本上沒有第二種途徑可以實現。2.對測試不利。3.與單一職責原則有沖突。餓漢式單例類與懶漢式單例類之間的區別：

1.餓漢式單例類在被加載時實例化，而懶漢式單例類在第一次引用時實例化。2.從資源利用效率上說，餓漢式單例類要差一點，但從速度和反應時間的角度來講，餓漢式單例類則比懶漢式單例類稍好些。

3.餓漢式單例類可以在Java中實現，但不易在C++中實現。單例模式的使用場景：

1.要求生成唯一的序列號環境。

2.在整個項目中需要一個共享訪問點或共享數據。3.創建一個對象需要消耗的資源過多。4.需要定義大量的靜態方法的環境。使用單例模式的注意事項：

1.在使用任何EJB、RMI和JINI的分布式系統中，應當避免使用有狀態的單例類。2.同一個JVM中會有多個類加載器，當兩個類加載器同時加載一個類時，會出現兩個實例，此時也應當盡量避免使用有狀態的單例類。

工廠方法模式：定義一個用于創建對象的接口，讓子類決定實例化那個類。

優點：良好的封裝性，代碼結構清晰；優秀的可擴展性；屏蔽產品類；典型的解耦框架。使用場景：1.工廠方法模式是new一個對象的替代品，故在所有需要生成對象的地方都可以使用，但是需要慎重考慮是否需要增加一個工廠類進行管理，增加代碼的復雜度。

2．需要靈活的、可擴展的框架時。3.可以用在異構項目中。

4.可以使用在測試驅動開發的框架下。

抽象工廠模式：為創建一組相關或相互依賴的對象提供一個接口，且無需指定它們的具體類。優點： 1.產品族內的約束為非公開狀態，在不同的工廠中，各種產品可能具有不同的相互依賴關系，這些依賴關系由工廠封裝在其內部，對于工廠的使用者是不可見的。

2.生產線的擴展非常容易，如果要針對同一產品族建立新的生產線，只需要實現產品族中的所有產品接口并建立新的工廠類即可。

缺點： 產品族本身的擴展非常困難，如果需要在產品族中增加一個新的產品類型，則需要修改多個接口，并且會影響已有的工廠類。

使用場景：當一個對象族（或是一組沒有任何關系的對象）都有相同的約束。

建造者將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。優點：1.封裝性，可以使客戶端不必知道產品內部組成的細節。2.建造者獨立，容易擴

3.便于控制細節風險。

使用場景：1.相同的方法，不同的執行順序，產生不同的結果。2.多個部件或零件，都可以裝配到一個對象中，但是產生的運行結果又不相同時。3.產品類非常復雜，或者產品類中的方法調用順序不同產生了不同的效能。4.在對象創建過程中會使用到系統的一些其他對象，這些對象在產品對象的創建過程中不易得到時。原型模式：用原型實例制定創建對象的種類，并且通過復制這些原型創建新的對象。優點：性能優良；逃避構造函數的約束。

使用場景：資源優化場景；性能和安全要求場景；一個對象多個修改者的場景。結構型模式：為其他對象提供一種代理以控制對這個對象的訪問。

種類：遠程代理、虛擬代理、保護代理、緩存代理、同步代理、智能引用代理

優點：1.職責清晰：真實的角色實現實際的業務邏輯，不用關心其他非本職的事務，通過后期的代理完成附加的事務，附帶的結果就是編程簡潔清晰。

2.高擴展性：具體主題角色隨需求不同可能有很多種，但只要實現了接口，代理類就完全可以在不做任何修改的情況下代理各種真實主題角色。

3.智能化：代理類可以在運行時才確定要去代理的真實主題，這是一種強大的功能。使用場景：代理模式的應用非常廣泛，大到一個系統框架、企業平臺，小到事務處理、代碼片段，隨處可見代理模式的使用，例如，JavaRMI的遠程調用和AOP。

裝飾模式：動態的給一個對象添加一些額外的職責。

優點：裝飾類和被裝飾類都可以獨立發展，而不會相互耦合；裝飾模式是繼承關系的一個替代方案；裝飾模式可以動態地擴展一個實現類的功能。

使用場景：1.需要擴展一個類的功能，或給一個類增加附加功能。

2.需要動態地給一個對象增加功能，這些功能可以再動態地撤銷。3.需要為一批類進行改裝或加裝功能。適配器模式：將一個類的接口變換成客戶端所期待的的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。

優點：可以讓兩個沒有任何關系的類在一起運行；增加了類的透明度；提高類的復用度；增強代碼的靈活性。

使用場景：修改一個已經投產中的系統時，需要對系統進行擴展。此時使用一個已有類，但這個類不符合系統中的接口，這是使用適配器模式是最合適的，它可以將不符合系統接口的類進行轉換，轉換成符合系統接口的、可以使用的類。

組合模式：將組合成樹形結構以表示“部分-整體”的層次結構，使得用戶對單個對象和組合對象的使用具有一致性。

優點：高層模塊調用簡單；節點自由增加。

缺點：不易控制樹枝構件的類型；不易使用繼承的方法來增加新的行為。

使用場景：1.需要描述對象的部分和整體的等級結構，如樹形菜單、文件和文件夾管理。2.需要客戶端忽略個體構件和組合構件的區別，平等對待所有的構件。橋梁模式：將抽象和現實解耦，使得兩者可以獨立地變化。優點：1.抽象和現實的分離是橋梁模式的主要特點，是為了解決繼承的缺點而提出的設計模式。在該模式下，實現可以不受抽象的約束，不用綁定在一個固定的抽象層次上。2.實現對客戶的透明，客戶端不用關心細節的實現，它已經由抽象層通過聚合關系完成了封裝。使用場合：1.如果一個系統需要在構件的抽象化角色和具體角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的聯系。

2.設計要求實現化角色的任何改變不應當影響客戶端，或者說實現化及角色的改變對客戶端是完全透明的。

3.一個構件有多于一個抽象化角色和實現化角色，系統需要它們之間進行動態耦合。4.不希望或不適合使用繼承的場合。

外觀模式：要求一個子系統的外部與其內部的通信必須通過一個統一的對象進行。

優點：1.減少系統的相互依賴，所有的依賴都是對Fa?ade對象的依賴，與子系統無關。

2．提高靈活性，不管子系統系統內部如何變化，只要不影響Fa?ade對象，任何活動都是自由的。

3.提高安全性，Fa?ade中未提供的方法，外界就無法訪問，提高系統的安全性。使用場景：1.為一個復雜的模塊或子系統提供一個供外界訪問的接口。

2.子系統相對獨立，外界子系統的訪問只要黑箱操作即可。3.預防風險擴散，使用Fa?ade進行訪問操作控制。

享元模式：使用共享對象可有效地支持大量的細粒度的對象。

優點：大幅減少內存中對象的數量，降低程序內存的占用，提高性能。缺點：1.增加了系統的復雜性，需要分出外部狀態和內部狀態，而且內部狀態具有固化特性，不應該隨外部狀態改變而改變，這使得程序的邏輯復雜化。

2.將享元對象的狀態外部化，而讀取外部狀態使得運行時間變長。使用場景：1.系統中有大量的相似對象，這些對象耗費大量的內存。

2．細粒度的對象都具備較接近的外部狀態，而且內部狀態與環境無關，即對象沒有特定身份。

3.需要緩沖池的場景。

模板方法模式：定義一個操作中的算法的框架，而將一些步驟延遲到子類中。使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。

優點：封裝不變的部分，擴展可變的部分；提取公共部分代碼，便于維護；行為由父類控制，子類實現。

應用場景：1.多個子類有公共方法，并且邏輯基本相同。

2.可以把重要的、復雜的、核心算法設計為模板方法，周邊的相關細節功能則由各個子類實現。

3.重構時，模板方法模式是一個經常使用的模式，將相同的代碼抽取到父類中。命令模式：將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日志，可以提供命令的撤銷和恢復功能。

優點：類間解耦；可擴展性；命令模式結合其他模式會更優秀。

缺點：可能會導致系統中出現過多的具體命令類，因此需要在項目中慎重考慮使用。應用場景：1.使用命令模式作為“回調”在面向對象系統中的替代；

2.需要在不同的時間指令請求、將請求排隊； 3.系統需要支持的撤銷（undo）；

4.需要將系統中所有的數據更新操作保存到日志里，以便在系統崩潰時，可以根據日志讀回所有的數據更新命令，重新調用execute（）方法一條一條執行這些命令，從而恢復系統在崩潰前所做的數據更新； 5.一個系統需要支持交易（transaction）。

責任鏈模式：使多個對象都有機會處理請求，從而避免請求的發送者和接受者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，知道有對象處理它為止。

優點：責任鏈模式將請求和處理分開，請求者不知道是誰處理的，處理者可以不用知道請求的全貌；提高系統的靈活性。

缺點：1.降低程序的性能，每個請求都是從鏈頭遍歷到鏈尾，當鏈比較長時，性能大幅下降。2.不易于調試，由于采用了類似遞歸的方式，調試的時候邏輯比較復雜。

應用場景：一個請求需要一系列的處理工作；業務流的處理，例如，文件審批；對系統進行補充擴展。策略模式：定義一組算法，將每個算法都封裝起來，并且使他們之間可以互換。

優點：提供了管理相關算法族的辦法；提供了可以替換繼承關系的方法；可以避免使用多重條件轉換語句。

缺點：客戶端必須知道所有的策略類，并自行決定使用哪一個策略類；策略模式造成很多的策略類。

應用場景：多個類只是在算法或行為上稍有不同的場景；算法需要自由切換的場景；需要屏蔽算法規則的場景。

迭代器模式：提供一種方法訪問一個容器對象中各個元素，又不需要暴露該對象的內部細節。優點：1.迭代器模式簡化了訪問容器元素的操作，具備一個統一的遍歷接口。2.封裝遍歷算法，使算法獨立于聚集角色。

缺點：1.迭代器模式給使用者一個序列化的錯覺，從而產生錯覺。2.迭代器的元素都是Object類型，沒有類型特征。

中介者模式：用一個中介對象封裝一系列對象（同事）的交互，中介者使對象不需要顯式地相互作用，從而使其耦合松散，而且可以獨立地改變他們之間的交互。

優點：1.減少類間的依賴，將原有的一對多的依賴變成一對一的依賴，使得對象之間的關系更以維護和理解。

2.避免同事對象之間過度耦合，同事類只依賴于中介者，使同事類更易被復用，中介類和同事類可以相互獨立地演化。

3.中介者模式將對象的行為和協作抽象化，將對象在小尺度的行為上與其他對象的相互作用分開處理。

缺點：1.中介者模式降低了同事對象的復雜性，但增加了中介者類的復雜性。

2.中介者類經常充滿了各個具體同事類的關系協調代碼，這種代碼是不能復用的。注意事項：不應當在責任劃分混亂時使用；不應當對數據類和方法類使用；正確理解封裝。觀察者模式：定義對象間一種一對多的依賴關系，使得每當一個對象改變狀態，則所有依賴于它的對象都會得到通知并被自動更新。

優點：觀察者和被觀察者之間是抽象耦合；支持廣播通信。缺點：1.如果一個主題有多個直接或者間接的觀察者，則通知所有的觀察者會花費很多時間，且開發和調試都比較復雜。

2.如果在主題之間有循環依賴，被觀察者會觸發他們間進行循環調用，導致系統崩潰。3.如果對觀察者的通知是通過另外線程進行異步投遞，系統必須保證投遞的順利執行。4．雖然觀察者模式可以隨時使觀察者知道所觀察的對象發生了變化，但是觀察者模式沒有提供相應的機制使觀察者知道所觀察的對象是如何發生變化。

應用場景：關聯行為場景；事件多級觸發場景；跨系統的消息交換場景。注意事項：廣播鏈的問題；異步處理的問題。

備忘錄模式：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。這樣，以后就可以將該對象恢復到原先保存的狀態。

應用場景：需要保存和恢復數據的相關場景狀態；提供一個可回滾的操作；需要監控副本的場景；數據庫連接的事務管理使用的就是備忘錄模式。

注意事項：1.備忘錄的生命周期。備忘錄創建出來就要在最近的代碼中使用，要主動管理它的生命周期，建立就要使用，不使用就要立刻刪除其引用，等待垃圾回收器對它的回收處理。

2．備忘錄的性能。不要頻繁建立備份的場景中使用備忘錄模式。

訪問者模式：封裝一些作用于某種數據結構中的各元素的操作，它可以在不改變數據結構的前提下定義作用于這些元素的新的操作。

優點：1.使得增加新的操作變得很容易，增加新的操作只需要增加新的訪問類。2.將有關的行為集中到一個訪問者對象中，而不是分散到一個個元素類中。3.訪問者模式可以跨過幾個類的等級結構訪問屬于不同等級結構的成員類。4．積累狀態。

缺點：增加新的元素類變得困難；破壞封裝；違背依賴倒置原則。

應用場景：1.一個對象結構類有很多類對象，它們有不同的接口，當這些對象實施依賴于具體類的操作時，即使用迭代器模式不能勝任的場景下，可以采用訪問者模式。

2.需要對一個對象結構中的對象進行很多不同且無關的操作，避免操作污染類。3.業務要求遍歷多個不同的對象，這本身也是訪問者模式的出發點，迭代器模式只能訪問同類或同接口的數據，而訪問者模式是對迭代器模式的擴充，可以遍歷不同的對象，執行不同的操作。

狀態模式：當一個對象內在狀態改變時允許改變行為，這個對象看起來像改變了其類型 優點：結構清晰；遵循設計原則；封裝性非常好。缺點：子類太多，不易管理。

效果：1.狀態模式需要對每一個系統可能取得的狀態創建一個狀態類的子類。2.由于每一個狀態都被包裝到了類里面，就可以不必采用過程性的處理方式，使長篇累牘的條件轉移語句。

3.可以在系統的不同部分使用相同的一些狀態類的對象。4.狀態模式會造成大量的小狀態類，但是可以使程序免于大量的條件轉移語句，使程序實際上更易維護。

5.系統所選的狀態子類均是從一個抽象狀態類或借口繼承而來，JAVA語言的特性使得在Java語言中使用狀態模式較為完全，多態性原則是狀態模式的核心。

使用場景：對象的行為依賴于它所處的狀態，即行為隨狀態改變而改變的場景；對象在某個方法里依賴于一重或多重條件分支語句。

解釋器模式：給定一門語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。

優點：簡單的語法分析工具；擴展性，修改語法規則只要修改相應的非終結符表達式即可，若擴展語法，則只要增加非終結符類即可。

缺點：解釋器模式會引起類膨脹；采用遞歸調用的方法。

使用場景：重復發生的問題可以使用解釋器模式；一個簡單語法需要解釋的場景。

第三篇：設計模式心得體會

設計模式心得體會

第一篇：設計模式

7月初的一個周末，準確的說應該是7月1號周六，在網上看到一本《大話設計模式》的書，而且看到很多很好的評論，于是乎，下載了電子書看看，一下子看了幾章之后，對設計模式有了個了解，于是繼續上網搜些其他資料，進一步了解設計模式。最終結論：設計模式是個好東西，具體怎么好，一兩句話是無法概括的，也是從那天起，我就決定學習設計模式，于是就看《大話設計模式》，至七月十多號，大概看了一百多頁后，感覺有點難，有點看不下去的感覺，于是上網找其他的好方法，無意間發現了李建忠老師的《c#設計模式縱橫談》系列講座，微軟的webcast課程，主要講解gof的xx個設計模式，每個一講，加上一頭一尾，共xx講，試聽了一節課后，感覺很有用，于是就抽時間去邊聽課邊看書，并在我的博客里寫下筆記，依賴加深印象，二來可以督促我的進度。

三個月以來，總算把設計模式學完一遍了，原計劃是兩個月學完（一星期三個模式），由于。計劃兩個月學完實際花了三個月，感觸多多，收獲多多——對c#語言有了更進一步的認識，對oo的思想有了更全面的了解。下一步在設計模式方面的計劃：鞏固并運用設計模式，鞏固：把《大話設計模式》，《設計模式》，《設計模式——可復用的面向對象基礎》，《敏捷軟件開發：原則、模式與實踐》這些書再結合起來系統的看一看，當然還會去買一些我手頭上沒有的關于設計模式的書；運用：部門前幾天也提倡用c#來改版vb程序，我想這是一個很好的平臺，正好有機會把理論的東西在實際中應用，理論加實際——唯一的學習方法。

下面對各個模式再簡單總結一下：

1、創建型模式：

singleton：解決的是實例化對象的個數的問題，比如抽象工廠中的工廠、對象池等，除了singleton之外，其他創建型模式解決的都是new所帶來的耦合關系。

abstractfactory：創建一系列相互依賴對象，并能在運行時改變系列。

factorymethod：創建單個對象，在abstractfactory有使用到。

prototype：通過拷貝原型來創建新的對象。

factorymethod，abstractfactory,builder都需要一個額外的工廠類來負責實例化一邊對象，而prototype則是通過原型（一個特殊的工廠類）來克隆易變對象。

如果遇到易變類，起初的設計通常從factorymethod開始，當遇到更多的復雜變化時，再考慮重構為其他三種工廠模式（factorymethod，abstractfactory,builder）。

2、結構性模式

adapter：注重轉換接口，將不吻合的接口適配對象，用于舊代碼復用、類庫遷移等。

bridge：注重實現抽象和實現的分離，支持對象多維度的變化。

composite：注重同意接口，將一對多的關系轉化為一對一的關系，屏蔽對象容器內部實現結構，實現對象和對象容器使用的一致性。

decorator：注重穩定接口，在此前提下為對象擴展功能，實現對象功能的擴展，避免子類膨脹。

facade：注重簡化接口，屏蔽各子系統的復雜性，提供更高層接口供客戶訪問。

flyweight：注重保留接口，在內部使用共享技術對對象存儲進行優化（通過共享大量細粒度對象，提供系統性能）。

proxy：注重假借接口，通過增加間接代理，實現更多控制，屏蔽復雜性。

3、行為型模式

templatemethod：封裝算法結構，定義算法骨架，支持算法子步驟變化。

strategy：注重封裝算法，支持算法的變化，通過封裝一系列算法，從而可以隨時獨立于客戶替換算法。

state：注重封裝與狀態相關的行為，支持狀態的變化，通過封裝對象狀態，從而在其內部狀態改變時改變它的行為。

memento：注重封裝對象狀態變化，支持狀態保存、恢復。

mediator：注重封裝對象間的交互，通過封裝一系列對象之間的復雜交互，使他們不需要顯式相互引用，實現解耦。

chainofresponsibility：注重封裝對象責任，支持責任的變化，通過動態構建職責鏈，實現事務處理。

command：注重將請求封裝為對象，支持請求的變化，通過將一組行為抽象為對象，實現行為請求者和行為實現者之間的解耦。

iterator：注重封裝特定領域變化，支持集合的變化，屏蔽集合對象內部復雜結構，提供客戶程序對它的透明遍歷。

interpreter：注重封裝特定領域變化，支持領域問題的頻繁變化，將特定領域的問題表達為某種語法規則下的句子，然后構建一個解釋器來解釋這樣的句子，從而達到解決問題的目的。

observer：注重封裝對象通知，支持通信對象的變化，實現對象狀態改變，通知依賴它的對象并更新。

visitor：注重封裝對象操作變化，支持在運行時為類結構添加新的操作，在類層次結構中，在不改變各類的前提下定義作用于這些類實例的新的操作。

正確對待模式：

設計模式建立在對系統變化點的基礎上進行，哪里有變化，哪里就應用設計模式。

設計模式應該以演化的方式來獲得，系統的變化點往往是經過不斷演化才能準確定位。

不能為了模式而模式，設計模式是一種軟件設計的軟力量，而非規范標準，不應夸大設計模式的作用。

設計模式心得體會（2）：

從一開始學習設計模式至今已半年有余了，第一次接觸設計模式是一次不經意間在網上看到《大話設計模式》一書，看了前言了第一章后，就感覺到其誘惑力對于一個程序員來說，是無比巨大的。大概是去年十月份的時候，部門決定成立讀書會，系統學習設計模式。

通過學習設計模式，除了學習到一些設計模式，還讓我進一步熟悉、鞏固了面向對象思想，進一步熟悉了c#語言。我曾多次設想，我們如果引入面向對象思想，并結合設計模式來重寫或改善我們的系統（必須重寫，雖說設計模式只是一種思想，語言只是實現而已，但是選擇一門好的語言，無疑也是非常重要的，而vb6在面向對象方面卻有很大欠缺甚至不具備其條件），那么我們的系統將會像目前一樣需要那么多人來維護嗎？

《大話設計模式》一書其實是對gof的《設計模式——可復用面向對象軟件的基礎》一書的翻譯，讓人更容易理解，用通俗易懂的語言闡述軟件設計過程中的一些模式，在某種特定環境下，用最好的設計方法（代碼高內聚，低耦合，使其有良好的可擴展性和可維護性）達到我們的目的，或許其方法有很多很多，但是尋找到最好的方法卻不是件容易的事，設計模式是對前人的設計經驗的一個總結，告訴我們在某種特定的環境下，這樣的設計師最好的，學習設計模式有助于我們在設計軟件的過程中少走很多彎路。

我對gof的xx個設計模式雖然都有看過，但是只有理解，實現，應用及思考之后，才能真正體會其精妙之處，至今體會較深的有以下幾個模式：1strategy——封裝系列算法，讓它們之間可以相互替換，算法并不是單指數據結構中的算法，在實踐中，它幾乎可以封裝任何類型的規則，這使得策略模式的運用極其廣泛；2templatemethod——有人說是用的做多的模式，只要有抽象類的地方，都可以看到這個模式，它通過把不變行為移到父類中去，去除子類中的重復代碼，從而提供了一個很好的代碼復用平臺；3facade——提供了對基礎架構的統一訪問，減少復雜性，在web編程者中的三層架構，就是此思想，每一層都封裝好一部分功能，提供給上一層統一的方法調用，整個framework體系就是facade模式的封裝，隨著xx升級到xx，越來越多復雜的高級功能被封裝，可以說facade無處不在；4abstractfactory——提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類，咋一看，太抽象了，說個例子，在三層架構中，bll層對dal層的調用會直接用到dal層中的類，如果dal層是分別對sqlserver，oracle的訪問，bll層需要根據實際情況決定實例化哪一個dal層中的類，我們又希望在兩種dal層切換時，bll層和ui層都不做改變，那么可在bll層和dal層中增加接口層（體現了抽象的精神，或者說是面向接口編程的最佳體現）和抽象工廠（dalfactroy），讓它來實例化dal層中的實例；5singleton——確保一個類僅有一個實例，并提供一個訪問它的全局訪問點，如單件窗體，點一下menu，彈出一個窗體(實例)，在關閉這個新窗體之前，再次點擊該menu，不會再次出現同樣的彈出窗體(實例)。篇幅有限，其他模式或多或少都有點感覺。

最后，引用《設計模式解析》書中的一句話：設計模式體現的是一種思想，而思想是指導行為的一切，理解和掌握了設計模式，并不是說記住了xx種（或更多）設計場景和解決策略（實際上這也是很重要的一筆財富），實際接受的是一種思想的熏陶和洗禮，等這種思想融入到了你的思想中后，你就會不自覺地使用這種思想去進行你的設計和開發，這一切才是最重要的。

第二篇：設計模式初學心得

以前沒有接觸過設計模式，那其實也是因為以前沒有真正經歷過面向對象的設計。這樣的情況在我經歷了本科畢業設計，并且遵循我們實驗室的一位師兄的建議看了《設計模式精解》（[美]alanshal(轉載請注明來源：)loway&jamesrtrott著，熊節譯）后有了根本的改變，我開始意識到一個程序員和一個設計者的區別，我也開始意識到在同學眼中“編程很強”的我只是——至少現在只是一個程序員。

我做的本科畢設是基于java-swing設計一個類似繪圖程序的系統，最終我設計出來的程序，在別人看來很不錯。但是只有我自己知道，我的設計其實是糟糕了，最明顯的就是低內聚、緊耦合，那些代碼甚至連我都不愿意去維護。于是當我看到書中的一句話：“幾乎百分之百的軟件都不是由它最初的設計者去維護的??”，更讓我感到這次設計的失敗（就連它的設計者都不原意去維護）。

《設計模式精解》的出現可以說讓我眼前一亮，這也是第一本讓我想再讀一次的書（即使現在我還沒有讀完）。究竟什么是模式？書中的解釋是“模式是針對特定場景下的特定問題的可重復、可表達的解決方案”，除此之外模式還必須有三個要點：

1．可重復性。解決方案應該對應于外部的場景。2．可傳授性。一個解決方案應該可以移植到問題的不同情況中（絕大多數模式的可傳授性都建立在“約束”和“效果”的基礎上）。

3．用來表示這個模式的名稱。

模式不限于面向對象，不限于設計階段，甚至不限于軟件開發領域。設計模式只是模式的一個子集。

在前言中作者說在他對現有的設計模式的指導原則及策略都非常清楚之后，這些原則幫助他決定開始過一種為人解惑的生活??雖然我第一次看到“為人解惑的生活”這個詞語，但是我立刻感到這也是我所向往的一種生活。

書中介紹了軟件開發過程中的三個不同視角：

1．概念視角。這個視角“展現了問題領域中的概念??一個概念模型可以在對實現軟件有很少或毫無注意的情況下畫出??”

2．規格視角。“只看軟件的接口，而不看實現” 3．實現視角。就是現在的我唯一使用的視角——置身于代碼之中。

看到這里我更加肯定了這本所講的是我從來沒有注意過的東西，但是我對這些東西應該非常感興趣，而我也深深地感慨：我為什么現在才看到這本書。在書中作者回顧了它從前的一個設計，通過不斷修改得出的優秀設計，逐步展現出設計模式的強大威力。書中有句話很經典——如果你只有一把錘子，那你會發現所有的東西都像釘子。意思是說如果你只知道一種解決問題的辦法，那你只會想用這個方法解決所有問題。我覺得這很像現在的我，在面向對象的設計中我幾乎只會“類繼承”，結果是我的畢設——過高的繼承體系導致緊耦合、低內聚。

當我學到書中介紹的第一個設計模式：facade模式，我立刻對這些設計模式產生了濃厚的興趣，我發現自己像一個“完美主義者”，在試圖追求結構完美的程序代碼（可讀性好、易于維護），而設計模式給我提供了這樣的可能，盡管我僅僅看到了它的一點點部分。設計模式就像一個漂亮的女孩，而且你知道她不僅外表很漂亮，也很有內涵，那你想做的事情還有什么呢？當然是盡快接近并了解她?? 第三篇：設計模式之心得

剛學幾天就有一些淺薄的心得了。

在學過的幾種設計模式中（目前為止，本人只學過創建性模式），每一種設計模式都會有一種具體的應用場景，每一種場景描述的都是一種需求變化。設計模式就是用來解決這些變化的。只要客戶有新的需求，你的程序就要發生改變，不管你用什么方法，這個改變是避免不了的。關鍵是你如何是解決這種變化！設計模式就是尋求一種通用的較好的方法來解決這種變化而不是避免這種變化，并不是你應用了設計模式，你的系統就不會發生變化了。

面向對象的編程有三大機制，我個人認為，設計模式很好的利用了其中的“封裝與多態”（當然并不是所有的設計模式都是這樣的，也不是說繼承就沒用，繼承在三大機制排第一呀，是基本的），比如工廠方法模式和生成器模式。“封裝”的意義不僅僅在于封裝代碼的實現，更重要的是“封裝”系統中變化的部分。設計模式回答了怎么樣去“封裝”這種變化。

在一個系統中，總會有一部分經常發生變化，相對的，也總有一個部分是改變頻率較低的，我們可以在某種范圍內將其理解為不改變的部分。設計模式要作的事情就是把“變化”的部分封裝起來，實現將“變化”的部分與“不變化”的部隔離，這樣，“變化”的部分在發生變化時，不會影響到“不改變”的部分。如果你也學過設計模式，那你可能跟我有同感。設計模式解決變化的途徑可以概括為兩步（純屬個人見解）：一是轉移變化，二是轉化變化。

首先是“轉移變化”。簡單的說就是把a部分的變化轉移到b部分，請b去變化，讓a不發生變化。在程序中就是將變化從調用者轉移到被調用者。比如，你有一個類scene，這個類用于顯現一種風格的游戲場景，調用程序實例化這個類并使用它。如果有一天，需求改變了，當前風格的游戲場景顏色太冷了，我需要改變當前場景的顏色。這個時候你要決定，要讓誰去發生變化？是讓客戶調用程序去改變scene類的顏色屬性呢，還是讓你的類scene發生變化？設計模式回答的是，請scene發生變化，調用者不發生變化。

為什么要這樣回答，因為這個時候，你的系統可能已經交付用戶了，如果讓調用者發生變化，那整個系統都要發生變化。（這里討論只是一個簡單的應用，實際情況中往往沒有這里簡單。如果實際情況是這么簡單的話，設計模式估計就沒有用處了。）

然后是“轉化變化”。

確定了要改動scene，那要怎么樣去改scene呢？直接改嗎？當然不行，如果是這樣改，那還不如讓調用者去設置scene的某個屬性呢，反正都要重新部署。那要怎么改？“擴展”，把這種“改變”轉化為“擴展”。你不是要另外一種

scene嗎？那我重新為你設計一個sence并生成dll交付你，然后讓現有的程序去調用這個scene。當然，這時可能需要調用者稍微的發生一下變化，比如開始調用者是直接調用scene來呈現場景的，現在將其改為根據配置文件來決定要呈現那種scene。但是如果之前你已經考慮到這個問題了，那調用者是不需要發生任何變化的，因為調用者是根據配置來決定所呈現的場景，需求發生彎化，只需要改變配置文件（可能是一個ｘｍｌ），把調用者與新添的scene關聯即可，這樣一來，“改動”就變為“擴展”，其帶來的好處也是顯而易見的，這也就是所謂的“開閉”原則。

以上文字完全是本人理解，隨著不斷的學習，我想這么文章估計要被改好多次，這是一個學習的過程。理解錯了、寫錯了都不要緊，關鍵是你怎么樣去面對這種錯誤！是拒絕承認錯誤還是正視錯誤？這也是設計模式回答的問題。

第四篇：洋思模式心得體會 洋思模式心得體會

從學習杜郎口到學習洋思已經好幾年了，每年每學期都要進行大規模的聽課活動，可謂轟轟烈烈，但學習了好幾年時間，我心中仍然一塌糊涂，一知半解，難以靈活運用，嘗試著運用時，也是提襟見肘，顧此失彼。所以成功的經驗很少，只能有一點粗略的感受。我覺得目標設計盡量的要簡潔明了，通俗易懂，要讓絕大多數學生能夠完成，如果太難或過于簡單，都不利于學生的學習。目標設計應控制在1----3條為宜，如果目標太多，一節課根本無法完成，那就白設計了，從學生的角度來說，當看到很多的目標時，心中會產生恐懼和排斥情緒，不利于學習。

由于條件限制，當堂訓練時只能采用課后練習和配套練習，缺少靈活性，對于在電子白板上做練習題，我總覺得效果不太好，因為一道題目看過后，印象不深，只有親手做過，才能記憶深刻。

其它環節，我正在努力嘗試、探索。第五篇：模式心得體會 教學模式心得體會

近幾年，我們在校領導的帶領下，實施了有本校特色的四大模塊，八大環節的課堂教學模式。通過我們幾年來的努力專研，現在，我們都可以很流暢的把我校的教學模式運用到我們的課堂教學中了，當然，在這幾年的專研中，我也有了自己的體會，現在，我就談談我個人的一些看法。

一、改變舊觀念，接受新模式 對于一個新的事物，需要通過不斷地學習去了解它，新的教學模式也是這樣。這學期，學校組織我們進行了多次學習，深入了解新模式的內涵、原則及實施細則，并組織我們通過數多次的教學研討課，讓我們真正了解這種模式的操作方法。不管是講座還是聽課教研，我都積極參加，積極與同行進行研究，認識到了新模式的確有助于培養學生自主學習的能力，有助于培養學生的合作意識，有助于學生學習能力的提高，有助于切實提高課堂效率。于是，我就積極在自己的課堂上進行嘗試，努力實現學生主體、教師主導的高效課堂。

二、把課堂還給學生

每節課上，我都不斷地提醒自己：“要放手，還給學生更多的學習時間。學生會的，教師不講；學生能說出來的，教師不說；學生通過談論能解決的，就讓學生討論解決。”有了這樣的意識，課上，學生活動的機會多了，學生讀書的時間有了，學生合作的機會有了，學生自主學習、獨立解決問題的能力提高了。課上，我只挑關鍵性的問題、共性問題組織教學，充分發揮激勵的作用，讓學生盡情地

展示自己。這樣，學生的學習熱情高漲，誰都想表現自己，誰都想得到大家的認可，學習效果有了提高。

三、把課前的準備做充分

每節課的教學，都需要教師事先的精心準備。我們的教學模式更是如此，哪怕就是指導學生怎樣預習。我剛開始帶的學生第一次接觸預習，學生不知道該怎樣下手，所以，手把手地教給方法就顯得尤為重要。我為了讓學生學會預習，我不怕耽誤課堂時間，親自在課堂上對學生預習的每一步進行指導，比如，我告訴學生要通過自己拼讀音標來學會讀單詞，要通過英漢互譯來熟練掌握單詞。我還要親自在課堂上指導學生如何寫預習筆記，如此反復，雖然學生的預習還是不能完全放手，但是，看到相當一部分學生已經開始自主地預習下一單元時，我還是感到很欣慰，畢竟小進步也比原地踏步強。

針對這幾年的英語教學，我也有點自己的看法：

一、靠持續不斷的語言知識，而不是“玩”來培養學生持久的興趣初中英語教學是要重視培養興趣，但單靠唱歌游戲不能培養學生持久的興趣。新鮮勁兒一過，孩子們就會厭倦。所以，唱歌游戲應該作為初中學生學習英語語言知識、技能的一些手段，而不是培養興趣的手段。我們可以采用多種手段幫助學生在記憶力強的時期多記單詞，多學習語言規則，并盡可能多創造模仿的機會，提高學生的語音和語調。在英語學習中，聽、說、讀、寫、譯五種能力是可以互補的。真正做到聽說先行，讀寫跟上。光聽說不讀寫，很難收到高效。只靠模仿不培養學習能力，也難減輕學習負擔。所以初中學生還是應

當認真進行語言學習。

二、英語應用能力需要相應的詞匯。“不學習語言規則、不掌握相當數量的詞匯，英語應用能力就是空中樓閣”。目前在中學的低年級的英語教學中，不要求學生掌握詞匯，而只要求學生能根據提示或圖片說出該單詞，其本質無非是要學生們死記硬背，鸚鵡學舌。由于學生們沒有相應的讀音規則訓練，不熟悉詞匯的拼寫規則，單詞的音、形、意三者不能有效的結合在一起，因而導致了單詞記憶的困難，并成了中學生學英語的瓶頸。

三、中學英語教師應有發展意識一向以來，人們中學英語教師的語言知識能力要求不高，認為中學英語簡單，不需要太好的語言功底，只要有良好的教學技能就可以了。其實時代在進步，社會在發展，同樣英語作為人們最廣泛的交際用語之一，更是隨著高科技的迅猛發展而日新月異地變化著。如果我們的英語教師故步自封，不求進取，那么不但自己的語言知識很快陳舊落伍，誤人子弟，而且會被時代所淘汰。“changingenglishinthechangingworld”。現代英語的變化，特別是口語方面的變化可從以下幾個方面體現出來：

1、隨著人們生活節奏的不斷加快，更因為國際互聯網的形成，人們之間的交際變得越來越簡捷。說話簡單快捷，是現代人生活的一大特征。現代英語在這方面的變化表現為“一字多用”。

2、隨著現代科學技術的迅猛發展，現代英語詞匯急劇增加，并且我們發現，現代英語詞匯有相當一部分是取得新義的舊詞，如，“input”(輸入電子計算機的數據)，“store”(電子計算機的儲存器)，“drive”(計

算機驅動器)等。

3、英國英語和美國英語之間的距離越來越小。也許是美國對世界政治、經濟影響日益強大的原因，美國英語的影響也越來越大，特別是對青少年的影響越來越大，他們以使用美語和發美國音為時髦。

當然，在實施新的教學模式的過程中我也有些困惑，譬如說學生由于作業量的增多而忽略了預習，導致課堂上不下去課的情況，我想，學校會為我們的教學模式的實施創造很好的條件的，相信在不久的將來，我們可以把教學模式變成我們自己的模式，在教學上更上一層樓

第四篇：設計模式小結

-----摘自設計模式之禪

一、創建類模式：

包括工廠方法模式、建造者模式、抽象工廠模式、單例模式和原型模式，提供對象的創建和管理職能。

1、單例模式是要保持在內存中只有一個對象。

2、原型模式是要求通過賦值的方式產生一個新的對象。

3、工廠方法模式和建造者模式都屬于對象創建類模式，都用來創建類的對象。區別：(1)意圖不同

工廠方法模式，關注的是一個產品整體。無須關注產品的各部分是如何創建出來的；建造者模式中，一個具體產品的產生是依賴各個部件的產生以及裝配順序，它關注的是“由零件一步一步地組裝出產品對象”。簡單的說，工廠模式是一個對象創建的組線條應用，建造者模式則是通過細線條勾勒出一個復雜對象，關注的產品組成部分的創建過程。(2)產品的復雜度不同

工廠方法模式創建的產品一般都是單一性質產品，而建造者模式創建的則是一個復合產品，它由各個部分復合而成，部件不同產品對象不同。它們的粒度大小不同，一般來說，工廠方法模式的對象粒度比較粗，建造者模式的產品對象粒度比較細。

4、抽象工廠模式比建造者模式的尺度要大，它關注產品整體，而建造者模式關注構建過程，因此建造者模式可以很容易地構建出一個嶄新的產品，只要導演類能夠提供具體的工藝流程。也正因為如何，兩者的應用場景截然不同，如果希望屏蔽對象的創建過程，只提供一個封裝良好的對象，則可以選擇抽象工廠方法模式。而建造者模式可以用在構件的裝配方面，如通過裝配不同的組件或者相同組件的不同順序，可以產生一個新的對象，它可以產生一個非常靈活的架構，方便地擴展和維護系統。

二、結構類模式 包括適配器模式、橋梁模式、組合模式、裝飾模式、門面模式、享元模式和代理模式。

1、代理模式與裝飾模式

代理模式是把當前的行為或功能委托給其他對象執行，代理類負責接口限定：是否可以調用真實角色，以及是否對發送到真實角色的消息進行變形處理，它不對被主題角色(被代理類)的功能做任務處理。代理模式使用到極致開發就是AOP，使用了代理和反射的技術。

裝飾模式是在要保證接口不變的情況下加強肋的功能，它保證的是被修飾的對象功能比原始對象豐富(或減弱),但不做準入條件判斷和準入參數過濾，如是否可以執行類的功能，過濾輸入參數是否合規等，這不是裝飾模式關心的。

在jdk的java.io.*包中大量使用裝飾模式

2、裝飾模式與適配器模式 a.意圖不同

裝飾模式的意圖是加強對象的功能，它不改變類的行為和屬性，只是增加（減弱）功能；而適配器莫斯關注的則是轉化，它的主要意圖是兩個不同對象之間的裝好，它關注轉換。b.施與對象不同

裝飾模式裝飾的對象必須是自己得同宗，也就是相同的接口或父類，只有在具有相同的屬性和行為的情況下，才能比較行為是增加還是減弱；適配器模式則必須是兩個不同的對象，因為它著重于裝換，只有兩個不同的對象才有裝換的必要。c.場景不同

裝飾模式在任何時候都可以使用，只要是想增強類的功能，而適配器模式則是一個補救模式，一般出現在系統成熟或已經構建完畢的項目中，作為一個緊急處理手段采用 d.擴展性不同

裝飾模式很容易擴展；但適配器模式建立模式，去除困難。

三、行為類模式 包括責任鏈模式、命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式、策略模式、模板方法模式、訪問者模式。

1、策略模式與命令模式

兩個模式相似，特別是命令模式退化時，如無接受者，這種情況下，兩個模式類圖完全一樣，代碼實現也比較相似，區別： a.關注點不同

策略模式關注的是算法替換的問題，一個新的算法投產，舊算法退休，或提供多種算法由調用者自己選擇使用，算法的自由更替是它實現的要點。換句話說，策略模式關注的是算法的完整性、封裝性，只有具備了這兩個條件才能保證其可以自由切換。

命令模式則關注的是解耦問題，如何讓請求者和執行者解耦是它需要首先解決的，解耦的要求就是把請求內容封裝為一個個的命令，由接收者執行。由于封裝成了命令，就同時可以對命令進行多種處理，例如撤銷、記錄等 b.角色功能不同

策略模式中的具體算法是負責一個完整的算法邏輯，它是不可再拆分的原子業務單元，一旦變更就是對算法整體的變更。

而命令模式則不同，它關注命令的實現，也就是功能的實現。接收者對命令負責，與請求者無關。命令模式中的接收者只要符合六大設計原則，完全不用關心它是否完成了一個具體邏輯，它的影響范圍也僅僅是抽象命令和具體命令，對它的修改不會擴散到模式外的模塊。

c.策略模式使用于算法要求變換的場景，而命令模式適用于解耦兩個有緊耦合關系的對象場合或多撤銷的場景。

2、策略模式與狀態模式 a.環境角色的職責不同

兩者都有一個叫做context環境角色的類，但區別很大，策略模式的環境角色只是一個委托左右，負責算法的替換；而狀態模式的環境角色不僅僅是委托行為，它還具有登記狀態變化的功能，與具體的狀態類協作，共同完成狀態切換行為隨之切換的任務 b.解決問題的重點不同

策略模式旨在解決內容算法如何改變的問題，也就是將內部算法的改變對外界的影響降低到最小程度，它保證的是算法可以自由地切換；而狀態模式旨在解決內在狀態的改變而引起行為改變的問題，它的出發點是事物的狀態，封裝狀態而暴露行為，一個對象的狀態改變，從外界來看好像是行為改變。c.解決問題的方法不同。

策略模式只是確保算法可以自由切換，但是什么時候用什么算法它決定不了；而狀態模式對外暴露的是行為，狀態的變化一般是由環境角色和具體狀態共同完成的，也就是說狀態模式封裝了狀態的變化而暴露了不同的行為或行為結果。d.應用場景不同

策略模式是一系列平行的、可相互替換的算法封裝后的結果，這就限定了它的應用場景：算法必須是平行的。狀態模式則要求有一系列狀態發生變化的場景，它要求的是有狀態且有行為的場景，也就是一個對象必須具有二維(狀態和行為)描述采用采用狀態模式，如果只有狀態而沒有行為，則狀態的變化就失去了意義。e.復雜度不同

通常策略模式結構簡單，易擴展。

狀態模式比較復雜，它封裝的是變化，而變化無窮。

3、觀察者模式(觸發鏈、觀察者鏈)與責任鏈模式 a.鏈中的消息對象不同

從首節點開始到最終的尾節點，兩個鏈中傳遞的消息對象是不同的。責任鏈模式基本不改變消息對象的結構，雖然每個節點都可以參與消費(一般不參與消防)，但它的結構不會改變；再觸發鏈模式中傳遞的對象是可以自由變換，只要上下級節點對傳遞對象了解即可，它不要求鏈中的消息對象不變化，它只要求鏈中相鄰兩個節點的消息對象固定

四、綜合1、2、b.上下節點的關系不同

在責任鏈模式中，上下節點沒有關系，都是接收同樣的對象，所有傳遞的對象都是從鏈首傳遞過來，上一節點是什么沒關系，只要按照自己得邏輯處理就成。而出發鏈模式就不同，它的上下級關系很親密，下級對上級頂禮膜拜，上級對下級絕對信任，鏈中的任意兩個相鄰節點都是一個牢固的獨立團體。c.消息的分銷渠道不同

再責任鏈模式中，一個消息從鏈首傳遞進來后，就開始沿著鏈條向鏈尾運動，方向是單一的、固定的；而觸發鏈模式則不同，由于它采用的是觀察者模式，所以有非常大的靈活性，一個消息傳遞到鏈首后，具體怎么傳遞是不固定的，可以以廣播方式傳遞，也可以以跳躍方式傳遞，取決于邏輯。

策略模式與橋梁模式

策略模式是一個行為模式，旨在封裝一系列的行為。而橋梁模式則是解決在不破壞封裝的情況下如何抽取出它的抽象部分和實現部分，它的前提是不破壞封裝，讓抽象部分和實現部分都可以獨立地變化。簡單的說，策略模式是使用和實現都可以獨立擴展的模式。橋梁模式必然有兩個“橋墩”-抽象化角色和實現化角色，只要橋墩搭建好，橋就有了，而策略模式只有一個抽象角色，可以沒有實現，也可以有很多實現。

門面模式與中介者模式

門面模式是以封裝和隔離為主要任務，而中介者模式則是以調和同事類之間的關系為主，因為要調和，所以具有了部分的業務邏輯控制。區別： a.功能區別

門面模式只是增加了一個門面，它對子系統來說沒有增加任務的功能，子系統若脫離門面模式是完全可以獨立原型的。而中介者模式則增加了業務功能，它把各個同事類中的原有耦合關系移植到了中介者，同事類不可能脫離中介者而獨立存在，除非是想增加系統的復雜性和降低擴展性。b.知曉狀態不同

對門面模式來說，子系統不知道有門面存在，而對中介者來說，每個同事類都知道中介者存在，因為要依靠中介者調和同事之間的關系，他們對中介者非常了解。c.封裝程度不同

門面模式是一種簡單的封裝，所有的請求處理都委托給子系統完成，而中介者模式則需要有一個中心，由中心協調同事類完成，并且中心本身也完成部分業務，它屬于更進一步的業務功能封裝。

第五篇：教學設計模式

教學設計模式——迪克-凱瑞模式

迪科-凱利（Dick & Carey）模式（如下圖）是典型的基于行為主義的教學系統開發模式。該模式從確定教學目標開始，到終結性評價結束，組成一個完整的教學系統開發過程。在該模式中，教學設計活動主要包括如下幾個方面：

（一）確定教學目標

教學目標的確定主要是通過對社會需求、學科特點以及學習者特點三個方面進行分析而得出。教學目標一般以可操作的行為目標形式加以描述。

（二）選用教學方法

在教學目標確定以后，接下來的工作就是如何實現教學目標的問題。教學方法的選用可以通過選用合適的教學策略以及教學材料得以實現。

（三）開展教學評價

這里的教學評價也包括形成性評價以及終結性評價兩個方面

迪克-凱瑞模式

教學設計模式——肯普模式

肯普（J.E.Kemp）認為，一個教學系統應包括四個基本要素，即學生、方法、目標和評價。也就是說，在進行教學設計時要考慮：這個教案或教材是為什么樣的人而設計的？希望這些人能學到什么？最好用什么方法來教授有關的教學內容？用什么方法和標準來衡量他們是否確實學會了？

肯普認為這四個基本要素及其關系是組成教學系統開發的出發點和大致框架，并由此引伸開去，提出了一個教學系統開發的橢園型結構模型，如下圖所示。該模式有幾個特點。

肯普模式

首先，肯普列出了10個教學設計的“因素”，而不稱之為步驟，以表示它的整體性以及設計過程之彈性。10 個因素雖然根據邏輯順時針排列，一般在設計一個新教學方案時可以按照這些順序進行，但肯普沒有用線條和箭頭將各因素連接起來，說明在某些情況和條件下，可能根本不必考慮或進行全部的因素（環節），或是由任何一個因素作為設計的起點，再依實際情況繼續下去。肯普以橢園形將10項因素圈在整個系統中，并以外圍的“評價”和“修改”表示這是兩件整個設計過程中持續進行的工作。這更顯示出系統方法的分析?設計?評價?反饋修正的工作策略實際上是在模式中每一因素（環節）中均執行的基本精神。因此，這個模式在形式上比其他許多流程型的模式更能反映系統論的觀念。

肯普模式的另一個特色是將“學習需要”、“教學目的”、“優先順序”和“約束條件”置于中心地位，以強調教學設計過程中必須隨機拿這幾個因素作為參考的依據。如前所述，教學系統是由一組有共同目標和相互關聯的因素所組成的，其作用范圍是人為設定的，因此，肯普將學習需要和教學目的置于中心正是突出了系統方法的以系統目標為導向的本質。同時，教學系統的設計過程離不開環境的制約：先考慮什么，后考慮什么，能做什么，不能做什么等等，都必須以環境的需要和可能為轉換。

肯普模式不象其他許多模式那樣只能按線性結構按部就班地進行設計，而是設計者可以根據自己的習慣和需要，選擇某個因素為起始點，并將其余因素按照任意邏輯程序進行排列；說明因素之間具有相對獨立性，如某些情況下不需要那一個因素便可不予考慮，避免了形式化；說明了因素之間的相互聯系性，一個因素所采取的決策會影響其他因素，一個因素決策內容變動，其相聯系的因素必須作一定的修改。

教學設計模式——尼文模式

尼文（N.Nieveen）在總結前人模式的基礎上，對教學開發模式進行了改進，將線性模式與環行模式相結合（如圖）。該模型更加直觀形象地描述了教學系統開發的真實過程，體現了如下兩個方面特點：

1.將原來的評估部分細化為形成性評價以及終結性評價兩部分。形成性評價的目的是在系統開發的過程中實施評價，便于提高系統性能；而終結性評價的目的則是在系統開發結束以后進行評價，對系統性能、效果等作出定性、定量的描述。2.設計、開發、實施以及形成性評價是一個循環往復的統一體。一個完善教學系統的開發，往往要經過幾個循環往復的過程才能實現。

尼文模式