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

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

創(chuàng)建型：

1.單件模式(Singleton Pattern)

2.抽象工廠（Abstract Factory）

3.建造者模式(Builder)

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

5.原型模式(Prototype)

結(jié)構(gòu)型：

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.職責(zé)鏈模式(Chain of Responsibility Pattern)

20.備忘錄模式(Memento Pattern)

21.策略模式(Strategy Pattern)

22.訪問者模式(Visitor Pattern)

23.狀態(tài)模式(State Pattern)

@Authorkwming

第二篇：Java23種設(shè)計模式6大原則總結(jié)

設(shè)計模式概念：一套被反復(fù)使用、多數(shù)人知曉、經(jīng)過分類編目的優(yōu)秀代碼設(shè)計經(jīng)驗的總結(jié)。設(shè)計模式要素：模式名稱、問題、舉例、末態(tài)環(huán)境、推理、其他有關(guān)模式、已知的應(yīng)用。設(shè)計模式分類：創(chuàng)建型、結(jié)構(gòu)型、行為型。

創(chuàng)建型模式功能：1.統(tǒng)所使用的具體類的信息封裝起來；

2.類的實例是如何被創(chuàng)建和組織的。

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

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

常見的創(chuàng)建型模式：單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式。常見的結(jié)構(gòu)型模式：代理模式、裝飾模式、適配器模式、組合模式、橋梁模式、外觀模式、享元模式。

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

單一職責(zé)原則：一個類應(yīng)該只有一個職責(zé)。

優(yōu)點：降低類的復(fù)雜性；提高類的可讀性；提高代碼的可維護性和復(fù)用性；降低因變更引起的風(fēng)險。

里氏替換原則：

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

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

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

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

依賴倒置原則：高層模塊不應(yīng)該依賴低層模塊，兩者都依賴其抽象；抽象不依賴細節(jié)；細節(jié)應(yīng)該依賴于抽象。

在Java中的表現(xiàn)：模塊間的依賴通過抽象發(fā)生，實現(xiàn)類之間不發(fā)生直接的依賴關(guān)系，其依賴關(guān)系是通過接口或抽象類產(chǎn)生的；接口或抽象類不依賴于是實現(xiàn)類；實現(xiàn)類依賴于接口或抽象類。

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

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

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

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

對迪米特法則進行模式設(shè)計有兩個：外觀模式、中介者模式。開閉原則：一個軟件實體應(yīng)當(dāng)對擴展開放，對修改關(guān)閉。

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

優(yōu)點：1.在內(nèi)存中只有一個實例，減少了內(nèi)存的開支。2.只生成一個實例，減少了系統(tǒng)的性能開銷。3.避免對資源的多重占用。

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

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

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

1.要求生成唯一的序列號環(huán)境。

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

1.在使用任何EJB、RMI和JINI的分布式系統(tǒng)中，應(yīng)當(dāng)避免使用有狀態(tài)的單例類。2.同一個JVM中會有多個類加載器，當(dāng)兩個類加載器同時加載一個類時，會出現(xiàn)兩個實例，此時也應(yīng)當(dāng)盡量避免使用有狀態(tài)的單例類。

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

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

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

4.可以使用在測試驅(qū)動開發(fā)的框架下。

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

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

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

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

建造者將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。優(yōu)點：1.封裝性，可以使客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié)。2.建造者獨立，容易擴

3.便于控制細節(jié)風(fēng)險。

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

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

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

優(yōu)點：1.職責(zé)清晰：真實的角色實現(xiàn)實際的業(yè)務(wù)邏輯，不用關(guān)心其他非本職的事務(wù)，通過后期的代理完成附加的事務(wù)，附帶的結(jié)果就是編程簡潔清晰。

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

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

裝飾模式：動態(tài)的給一個對象添加一些額外的職責(zé)。

優(yōu)點：裝飾類和被裝飾類都可以獨立發(fā)展，而不會相互耦合；裝飾模式是繼承關(guān)系的一個替代方案；裝飾模式可以動態(tài)地擴展一個實現(xiàn)類的功能。

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

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

優(yōu)點：可以讓兩個沒有任何關(guān)系的類在一起運行；增加了類的透明度；提高類的復(fù)用度；增強代碼的靈活性。

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

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

優(yōu)點：高層模塊調(diào)用簡單；節(jié)點自由增加。

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

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

2.設(shè)計要求實現(xiàn)化角色的任何改變不應(yīng)當(dāng)影響客戶端，或者說實現(xiàn)化及角色的改變對客戶端是完全透明的。

3.一個構(gòu)件有多于一個抽象化角色和實現(xiàn)化角色，系統(tǒng)需要它們之間進行動態(tài)耦合。4.不希望或不適合使用繼承的場合。

外觀模式：要求一個子系統(tǒng)的外部與其內(nèi)部的通信必須通過一個統(tǒng)一的對象進行。

優(yōu)點：1.減少系統(tǒng)的相互依賴，所有的依賴都是對Fa?ade對象的依賴，與子系統(tǒng)無關(guān)。

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

3.提高安全性，F(xiàn)a?ade中未提供的方法，外界就無法訪問，提高系統(tǒng)的安全性。使用場景：1.為一個復(fù)雜的模塊或子系統(tǒng)提供一個供外界訪問的接口。

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

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

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

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

2．細粒度的對象都具備較接近的外部狀態(tài)，而且內(nèi)部狀態(tài)與環(huán)境無關(guān)，即對象沒有特定身份。

3.需要緩沖池的場景。

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

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

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

2.可以把重要的、復(fù)雜的、核心算法設(shè)計為模板方法，周邊的相關(guān)細節(jié)功能則由各個子類實現(xiàn)。

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

優(yōu)點：類間解耦；可擴展性；命令模式結(jié)合其他模式會更優(yōu)秀。

缺點：可能會導(dǎo)致系統(tǒng)中出現(xiàn)過多的具體命令類，因此需要在項目中慎重考慮使用。應(yīng)用場景：1.使用命令模式作為“回調(diào)”在面向?qū)ο笙到y(tǒng)中的替代；

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

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

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

優(yōu)點：責(zé)任鏈模式將請求和處理分開，請求者不知道是誰處理的，處理者可以不用知道請求的全貌；提高系統(tǒng)的靈活性。

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

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

優(yōu)點：提供了管理相關(guān)算法族的辦法；提供了可以替換繼承關(guān)系的方法；可以避免使用多重條件轉(zhuǎn)換語句。

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

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

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

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

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

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

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

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

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

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

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

2.如果在主題之間有循環(huán)依賴，被觀察者會觸發(fā)他們間進行循環(huán)調(diào)用，導(dǎo)致系統(tǒng)崩潰。3.如果對觀察者的通知是通過另外線程進行異步投遞，系統(tǒng)必須保證投遞的順利執(zhí)行。4．雖然觀察者模式可以隨時使觀察者知道所觀察的對象發(fā)生了變化，但是觀察者模式?jīng)]有提供相應(yīng)的機制使觀察者知道所觀察的對象是如何發(fā)生變化。

應(yīng)用場景：關(guān)聯(lián)行為場景；事件多級觸發(fā)場景；跨系統(tǒng)的消息交換場景。注意事項：廣播鏈的問題；異步處理的問題。

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

應(yīng)用場景：需要保存和恢復(fù)數(shù)據(jù)的相關(guān)場景狀態(tài)；提供一個可回滾的操作；需要監(jiān)控副本的場景；數(shù)據(jù)庫連接的事務(wù)管理使用的就是備忘錄模式。

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

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

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

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

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

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

2.需要對一個對象結(jié)構(gòu)中的對象進行很多不同且無關(guān)的操作，避免操作污染類。3.業(yè)務(wù)要求遍歷多個不同的對象，這本身也是訪問者模式的出發(fā)點，迭代器模式只能訪問同類或同接口的數(shù)據(jù)，而訪問者模式是對迭代器模式的擴充，可以遍歷不同的對象，執(zhí)行不同的操作。

狀態(tài)模式：當(dāng)一個對象內(nèi)在狀態(tài)改變時允許改變行為，這個對象看起來像改變了其類型 優(yōu)點：結(jié)構(gòu)清晰；遵循設(shè)計原則；封裝性非常好。缺點：子類太多，不易管理。

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

3.可以在系統(tǒng)的不同部分使用相同的一些狀態(tài)類的對象。4.狀態(tài)模式會造成大量的小狀態(tài)類，但是可以使程序免于大量的條件轉(zhuǎn)移語句，使程序?qū)嶋H上更易維護。

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

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

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

優(yōu)點：簡單的語法分析工具；擴展性，修改語法規(guī)則只要修改相應(yīng)的非終結(jié)符表達式即可，若擴展語法，則只要增加非終結(jié)符類即可。

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

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

第三篇：設(shè)計模式心得體會

設(shè)計模式心得體會

第一篇：設(shè)計模式

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

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

下面對各個模式再簡單總結(jié)一下：

1、創(chuàng)建型模式：

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

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

factorymethod：創(chuàng)建單個對象，在abstractfactory有使用到。

prototype：通過拷貝原型來創(chuàng)建新的對象。

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

如果遇到易變類，起初的設(shè)計通常從factorymethod開始，當(dāng)遇到更多的復(fù)雜變化時，再考慮重構(gòu)為其他三種工廠模式（factorymethod，abstractfactory,builder）。

2、結(jié)構(gòu)性模式

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

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

composite：注重同意接口，將一對多的關(guān)系轉(zhuǎn)化為一對一的關(guān)系，屏蔽對象容器內(nèi)部實現(xiàn)結(jié)構(gòu)，實現(xiàn)對象和對象容器使用的一致性。

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

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

flyweight：注重保留接口，在內(nèi)部使用共享技術(shù)對對象存儲進行優(yōu)化（通過共享大量細粒度對象，提供系統(tǒng)性能）。

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

3、行為型模式

templatemethod：封裝算法結(jié)構(gòu)，定義算法骨架，支持算法子步驟變化。

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

state：注重封裝與狀態(tài)相關(guān)的行為，支持狀態(tài)的變化，通過封裝對象狀態(tài)，從而在其內(nèi)部狀態(tài)改變時改變它的行為。

memento：注重封裝對象狀態(tài)變化，支持狀態(tài)保存、恢復(fù)。

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

chainofresponsibility：注重封裝對象責(zé)任，支持責(zé)任的變化，通過動態(tài)構(gòu)建職責(zé)鏈，實現(xiàn)事務(wù)處理。

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

iterator：注重封裝特定領(lǐng)域變化，支持集合的變化，屏蔽集合對象內(nèi)部復(fù)雜結(jié)構(gòu)，提供客戶程序?qū)λ耐该鞅闅v。

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

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

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

正確對待模式：

設(shè)計模式建立在對系統(tǒng)變化點的基礎(chǔ)上進行，哪里有變化，哪里就應(yīng)用設(shè)計模式。

設(shè)計模式應(yīng)該以演化的方式來獲得，系統(tǒng)的變化點往往是經(jīng)過不斷演化才能準(zhǔn)確定位。

不能為了模式而模式，設(shè)計模式是一種軟件設(shè)計的軟力量，而非規(guī)范標(biāo)準(zhǔn)，不應(yīng)夸大設(shè)計模式的作用。

設(shè)計模式心得體會（2）：

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

通過學(xué)習(xí)設(shè)計模式，除了學(xué)習(xí)到一些設(shè)計模式，還讓我進一步熟悉、鞏固了面向?qū)ο笏枷耄M一步熟悉了c#語言。我曾多次設(shè)想，我們?nèi)绻朊嫦驅(qū)ο笏枷?，并結(jié)合設(shè)計模式來重寫或改善我們的系統(tǒng)（必須重寫，雖說設(shè)計模式只是一種思想，語言只是實現(xiàn)而已，但是選擇一門好的語言，無疑也是非常重要的，而vb6在面向?qū)ο蠓矫鎱s有很大欠缺甚至不具備其條件），那么我們的系統(tǒng)將會像目前一樣需要那么多人來維護嗎？

《大話設(shè)計模式》一書其實是對gof的《設(shè)計模式——可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書的翻譯，讓人更容易理解，用通俗易懂的語言闡述軟件設(shè)計過程中的一些模式，在某種特定環(huán)境下，用最好的設(shè)計方法（代碼高內(nèi)聚，低耦合，使其有良好的可擴展性和可維護性）達到我們的目的，或許其方法有很多很多，但是尋找到最好的方法卻不是件容易的事，設(shè)計模式是對前人的設(shè)計經(jīng)驗的一個總結(jié)，告訴我們在某種特定的環(huán)境下，這樣的設(shè)計師最好的，學(xué)習(xí)設(shè)計模式有助于我們在設(shè)計軟件的過程中少走很多彎路。

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

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

第二篇：設(shè)計模式初學(xué)心得

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

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

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

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

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

模式不限于面向?qū)ο?，不限于設(shè)計階段，甚至不限于軟件開發(fā)領(lǐng)域。設(shè)計模式只是模式的一個子集。

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

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

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

2．規(guī)格視角?！爸豢窜浖慕涌?，而不看實現(xiàn)” 3．實現(xiàn)視角。就是現(xiàn)在的我唯一使用的視角——置身于代碼之中。

看到這里我更加肯定了這本所講的是我從來沒有注意過的東西，但是我對這些東西應(yīng)該非常感興趣，而我也深深地感慨：我為什么現(xiàn)在才看到這本書。在書中作者回顧了它從前的一個設(shè)計，通過不斷修改得出的優(yōu)秀設(shè)計，逐步展現(xiàn)出設(shè)計模式的強大威力。書中有句話很經(jīng)典——如果你只有一把錘子，那你會發(fā)現(xiàn)所有的東西都像釘子。意思是說如果你只知道一種解決問題的辦法，那你只會想用這個方法解決所有問題。我覺得這很像現(xiàn)在的我，在面向?qū)ο蟮脑O(shè)計中我?guī)缀踔粫邦惱^承”，結(jié)果是我的畢設(shè)——過高的繼承體系導(dǎo)致緊耦合、低內(nèi)聚。

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

剛學(xué)幾天就有一些淺薄的心得了。

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

面向?qū)ο蟮木幊逃腥髾C制，我個人認為，設(shè)計模式很好的利用了其中的“封裝與多態(tài)”（當(dāng)然并不是所有的設(shè)計模式都是這樣的，也不是說繼承就沒用，繼承在三大機制排第一呀，是基本的），比如工廠方法模式和生成器模式?！胺庋b”的意義不僅僅在于封裝代碼的實現(xiàn)，更重要的是“封裝”系統(tǒng)中變化的部分。設(shè)計模式回答了怎么樣去“封裝”這種變化。

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

首先是“轉(zhuǎn)移變化”。簡單的說就是把a部分的變化轉(zhuǎn)移到b部分，請b去變化，讓a不發(fā)生變化。在程序中就是將變化從調(diào)用者轉(zhuǎn)移到被調(diào)用者。比如，你有一個類scene，這個類用于顯現(xiàn)一種風(fēng)格的游戲場景，調(diào)用程序?qū)嵗@個類并使用它。如果有一天，需求改變了，當(dāng)前風(fēng)格的游戲場景顏色太冷了，我需要改變當(dāng)前場景的顏色。這個時候你要決定，要讓誰去發(fā)生變化？是讓客戶調(diào)用程序去改變scene類的顏色屬性呢，還是讓你的類scene發(fā)生變化？設(shè)計模式回答的是，請scene發(fā)生變化，調(diào)用者不發(fā)生變化。

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

然后是“轉(zhuǎn)化變化”。

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

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

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

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

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

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

其它環(huán)節(jié)，我正在努力嘗試、探索。第五篇：模式心得體會 教學(xué)模式心得體會

近幾年，我們在校領(lǐng)導(dǎo)的帶領(lǐng)下，實施了有本校特色的四大模塊，八大環(huán)節(jié)的課堂教學(xué)模式。通過我們幾年來的努力專研，現(xiàn)在，我們都可以很流暢的把我校的教學(xué)模式運用到我們的課堂教學(xué)中了，當(dāng)然，在這幾年的專研中，我也有了自己的體會，現(xiàn)在，我就談?wù)勎覀€人的一些看法。

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

二、把課堂還給學(xué)生

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

展示自己。這樣，學(xué)生的學(xué)習(xí)熱情高漲，誰都想表現(xiàn)自己，誰都想得到大家的認可，學(xué)習(xí)效果有了提高。

三、把課前的準(zhǔn)備做充分

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

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

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

當(dāng)認真進行語言學(xué)習(xí)。

二、英語應(yīng)用能力需要相應(yīng)的詞匯?！安粚W(xué)習(xí)語言規(guī)則、不掌握相當(dāng)數(shù)量的詞匯，英語應(yīng)用能力就是空中樓閣”。目前在中學(xué)的低年級的英語教學(xué)中，不要求學(xué)生掌握詞匯，而只要求學(xué)生能根據(jù)提示或圖片說出該單詞，其本質(zhì)無非是要學(xué)生們死記硬背，鸚鵡學(xué)舌。由于學(xué)生們沒有相應(yīng)的讀音規(guī)則訓(xùn)練，不熟悉詞匯的拼寫規(guī)則，單詞的音、形、意三者不能有效的結(jié)合在一起，因而導(dǎo)致了單詞記憶的困難，并成了中學(xué)生學(xué)英語的瓶頸。

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

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

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

算機驅(qū)動器)等。

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

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

第四篇：設(shè)計模式小結(jié)

-----摘自設(shè)計模式之禪

一、創(chuàng)建類模式：

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

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

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

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

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

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

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

二、結(jié)構(gòu)類模式 包括適配器模式、橋梁模式、組合模式、裝飾模式、門面模式、享元模式和代理模式。

1、代理模式與裝飾模式

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

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

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

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

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

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

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

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

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

1、策略模式與命令模式

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

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

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

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

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

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

2、策略模式與狀態(tài)模式 a.環(huán)境角色的職責(zé)不同

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

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

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

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

通常策略模式結(jié)構(gòu)簡單，易擴展。

狀態(tài)模式比較復(fù)雜，它封裝的是變化，而變化無窮。

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

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

四、綜合1、2、b.上下節(jié)點的關(guān)系不同

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

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

策略模式與橋梁模式

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

門面模式與中介者模式

門面模式是以封裝和隔離為主要任務(wù)，而中介者模式則是以調(diào)和同事類之間的關(guān)系為主，因為要調(diào)和，所以具有了部分的業(yè)務(wù)邏輯控制。區(qū)別： a.功能區(qū)別

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

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

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

第五篇：教學(xué)設(shè)計模式

教學(xué)設(shè)計模式——迪克-凱瑞模式

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

（一）確定教學(xué)目標(biāo)

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

（二）選用教學(xué)方法

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

（三）開展教學(xué)評價

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

迪克-凱瑞模式

教學(xué)設(shè)計模式——肯普模式

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

肯普認為這四個基本要素及其關(guān)系是組成教學(xué)系統(tǒng)開發(fā)的出發(fā)點和大致框架，并由此引伸開去，提出了一個教學(xué)系統(tǒng)開發(fā)的橢園型結(jié)構(gòu)模型，如下圖所示。該模式有幾個特點。

肯普模式

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

肯普模式的另一個特色是將“學(xué)習(xí)需要”、“教學(xué)目的”、“優(yōu)先順序”和“約束條件”置于中心地位，以強調(diào)教學(xué)設(shè)計過程中必須隨機拿這幾個因素作為參考的依據(jù)。如前所述，教學(xué)系統(tǒng)是由一組有共同目標(biāo)和相互關(guān)聯(lián)的因素所組成的，其作用范圍是人為設(shè)定的，因此，肯普將學(xué)習(xí)需要和教學(xué)目的置于中心正是突出了系統(tǒng)方法的以系統(tǒng)目標(biāo)為導(dǎo)向的本質(zhì)。同時，教學(xué)系統(tǒng)的設(shè)計過程離不開環(huán)境的制約：先考慮什么，后考慮什么，能做什么，不能做什么等等，都必須以環(huán)境的需要和可能為轉(zhuǎn)換。

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

教學(xué)設(shè)計模式——尼文模式

尼文（N.Nieveen）在總結(jié)前人模式的基礎(chǔ)上，對教學(xué)開發(fā)模式進行了改進，將線性模式與環(huán)行模式相結(jié)合（如圖）。該模型更加直觀形象地描述了教學(xué)系統(tǒng)開發(fā)的真實過程，體現(xiàn)了如下兩個方面特點：

1.將原來的評估部分細化為形成性評價以及終結(jié)性評價兩部分。形成性評價的目的是在系統(tǒng)開發(fā)的過程中實施評價，便于提高系統(tǒng)性能；而終結(jié)性評價的目的則是在系統(tǒng)開發(fā)結(jié)束以后進行評價，對系統(tǒng)性能、效果等作出定性、定量的描述。2.設(shè)計、開發(fā)、實施以及形成性評價是一個循環(huán)往復(fù)的統(tǒng)一體。一個完善教學(xué)系統(tǒng)的開發(fā)，往往要經(jīng)過幾個循環(huán)往復(fù)的過程才能實現(xiàn)。

尼文模式