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

設計模式心得體會

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

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

通過學習設計模式，除了學習到一些設計模式，還讓我進一步熟悉、鞏固了面向對象思想，進一步熟悉了c#語言。。我曾多次設想，我們如果引入面向對象思想，并結合設計模式來重寫或改善我們的系統（必須重寫，雖說設計模式只是一種思想，語言只是實現而已，但是選擇一門好的語言，無疑也是非常重要的，而vb6在面向對象方面卻有很大欠缺甚至不具備其條件），那么我們的系統將會像目前一樣需要那么多人來維護嗎？ 《大話設計模式》一書其實是對gof的《設計模式可復用面向對象軟件的基礎》一書的翻譯，讓人更容易理解，用通俗易懂的語言闡述軟件設計過程中的一些模式，在某種特定環境下，用最好的設計方法（代碼高內聚，低耦合，使其有良好的可擴展性和可維護性）達到我們的目的，或許其方法有很多很多，但是尋找到最好的方法卻不是件容易的事，設計模式是對前人的設計經驗的一個總結，告訴我們在某種特定的環境下，這樣的設計師最好的，學習設計模式有助于我們在設計軟件的過程中少走很多彎路。

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

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

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

設計模式心得體會

第一篇：設計模式

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

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

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條為宜，如果目標太多，一節課根本無法完成，那就白設計了，從學生的角度來說，當看到很多的目標時，心中會產生恐懼和排斥情緒，不利于學習。

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

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

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

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

二、把課堂還給學生

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

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

三、把課前的準備做充分

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

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

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

當認真進行語言學習。

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

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

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

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

算機驅動器)等。

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

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

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

設計模式心得體會

----------計算機學院軟件工程14-1BF 黃東東

通過一個學期的設計模式的學習，我想在這里談一談我在學習設計模式中的一些想法，不一定正確，首先我對設計模式的理解是分階段的：

一、這是些什么亂七八糟的東西？那時候剛聽到了老師講設計模式的概念的感覺，聽不懂我就跑圖書館借了一本名字叫《設計模式初學者入門》之類的書。書里就把各種設計模式挨個講了遍，引用一下每個設計模式的定義，給個類圖，配點代碼??我硬著頭皮讀完之后，就一個感覺，為什么一個很簡單、很直接就能實現的功能，為什么要添那么多的類，繞那么多的彎？覺并沒有什么了不起的地方。所以前幾次課難免會比較懶散不以為意，這時候老師開始講工廠模式和建造模式，工廠模式是我們最常用的實例化對象模式了，是用工廠方法代替new操作的一模式，我們經常要根據類Class生成實例對象，如A a=new A()工廠模式也是用來創建實例對象的，所以以后new時就要多個心眼，是否可以考慮使用工廠模式，雖然這樣做，可能多做一些 工作，但會給你系統帶來更大的可擴展性和盡量少的修改量。建造模就是將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。我第一次感覺這種方法很實用，老師也稱之為“套路“，感覺上很有用，我產生了濃厚的興趣。

二、我開始看其他的書，這時候我讀到了程杰的《大話設計模式》，其中用活字印刷的例子，講解了曹操“對酒當歌，人生幾何”的敢動，我仿佛一下子就開竅了。明白了設計模式，他最重要的目的就是為了應對“變化”。一般的設計模式，目標比較“復雜”，并不是我所想的那么單刀直入，我們想的往往過于簡單了，最后什么都做不出來，我們需要這樣的套路，我們需要設計模式，我開始認真學。

三、但僅僅知道了設計模式的目標，還是沒有解決我的疑惑。我記得當時我心里反反復復的一個問題，“有變化，改代碼就行了呀。怎么改都是改，為什么就一定要像設計模式說的那樣改呢？”那時候我基本上是單兵作戰，代碼是自己一個人從頭寫到腳，哪里有問題我就可以改哪里，完全沒有心理負擔。后來一想以后的工作會有變動，會開始團隊開發、會維護別人的代碼等等。我就自然而然的明白了，有些代碼，是你只能用不能改的！典型的就是人家只給你一個已經編譯的dll，你怎么改？所以，我上課開始發現老師講的大概是什么了，我覺得十分的重要，那時候，我最先明白的就是橋接模式，在軟件系統中，某些類型由于自身的邏輯，它具有兩個或多個維度的變化，這就要使用Bridge模式應對這種“多維度的變化”，也就是橋接模式，它利用面向對象的技術來使得該類型能夠輕松的沿著多個方向進行變化，而又不引入額外的復雜度，所謂抽象和實現沿著各自維度的變化，即“子類化”它們，得到各個子類之后，便可以任意它們。以達到你的目的，Bridge模式有時候類似于多繼承方案，但是多繼承方案往往違背了類的單一職責原則（即一個類只有一個變化的原因），復用性比較差。Bridge模式是比多繼承方案更好的解決方法。，另一個就是Bridge模式的應用一般在“兩個非常強的變化維度”，有時候即使有兩個變化的維度，但是某個方向的變化維度并不劇烈——換言之兩個變化不會導致縱橫交錯的結果，并不一定要使用Bridge模式。

四、如果說上面這個階段是被動學習設計模式，照葫蘆畫瓢，接下來就是我開始主動的思考和使用設計模式了，在一些編碼過程中，我都會主動的思考，能不能套用某種設計模式，但是對于學生來說，時間太少了，又要上課又要各種考試各種會議各種復習考試，所以一一直擠時間，談不上真正的理解設計模式的核心思想。我認為我目前仍然沒有達到這個程度，雖然可以隨口說出一些耳熟能詳的設計模式特點，但理解仍然不深，很多時候覺得這也可那也可，拿不定主意。我覺得這是我代碼寫得太少的原因，需要在更多的實踐中體會提高。

看完這些，我對學習設計模式是持支持肯定態度的。那么，下面和大家交流一下學習設計模式的方法吧。

一、實踐。記得金旭亮老師曾經說過，“沒有寫過10萬行代碼，不要談設計模式”，可能有點夸張，但道理是棒棒的。如果沒有不得不深入到那些足夠復雜足夠混亂的代碼，身心飽受摧殘，不可能對設計模式的認識有質的提高。因為設計模式的一個重要應用場景，是應付那些復雜的業務邏輯、快速的需求變化，它的價值在這些地方，才能夠清晰的體現出來?！白摰馈笔且环N我們都期望的“懶人模式”，但估計很難有效——至少對于我這種資質平庸的人來說吧。

二、明白設計模式的目的。每一個設計模式，一定是要解決一定的問題的；并且解決這些問題是附帶了條件的。比如，需求發生了變更，這是問題。如果沒有其他約束，解決這個問題的辦法很簡單，就是改代碼而已，加上一個if...else而已。但是，我們不能這樣改！我們不能修改類里面的代碼，我們只能采取一些其他手段，比如繼承、比如封裝原有類，來實現新需求。這時候，設計模式就粉墨登場了。

三、上面所說，為什么不能直接改類里面的方法函數，比如直接加if...else？我們可以從兩方面理解。一方面是“被動的”，比如我們是引用的一個編譯了的dll，根本就改不了；或者是團隊開發，別人不允許你改他們寫好的類。另一方面是“主動的”，接前面“團隊開發，別人不允許你改他們寫好的類”，為什么他們不允許你改呢？是不是他們固執、偷懶，沒有團隊精神？你把官司打到大BOSS那里，可能會被一頓K。你需要仔細的體會，“類”的概念。類就是一種封裝，封裝就意味著拒絕修改你只需首先明白，設計模式，是一種“帶著腳鐐的舞蹈”；然后進一步思考為什么需要這些腳鐐。想通了就好了。最后，我還是強調“實踐”，如果想要更好的理解第二條唯一有效的方法，可能就是實踐了。這就是我學習設計模式的心得，希望對更多人有用（至少對我有用?。?/p>

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

設計模式心得體會

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

三個月以來，總算把設計模式學完一遍了，原計劃是兩個月學完，由于。。計劃兩個月學完實際花了三個月，感觸多多，收獲多多——對c#語言有了更進一步的認識，對oo的思想有了更全面的了解。。

下一步在設計模式方面的計劃：鞏固并運用設計模式，鞏固：把《大話設計模式》，《設計模式》，《設計模式——可復用的面向對象基礎》，《敏捷軟件開發：原則、模式與實踐》這些書再結合起來系統的看一看，當然還會去買一些我手頭上沒有的關于設計模式的書；運用：部門前幾天也提倡用c#來改版vb程序，我想這是一個很好的平臺，正好有機會把理論的東西在實際中應用，理

論加實際——唯一的學習方法。。

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

1、創建型模式：

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

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

factory method：創建單個對象，在abstract factory有使用到。

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

factory method，abstract factory, builder都需要一個額外的工廠類來負責實例化“一邊對象”，而prototype則是通過原型來克隆“易變對象”。

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

2、結構性模式

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

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

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

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

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

flyweight：注重保留接口，在內部使用共享技術對對象存儲進行優化。

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

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

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

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

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

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

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

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

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

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

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

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

正確對待模式：

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

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

不能為了模式而模式，設計模式是

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

設計模式心得體會：

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

通過學習設計模式，除了學習到“一些設計模式”，還讓我進一步熟悉、鞏固了面向對象思想，進一步熟悉了c#語言。。我曾多次設想，我們如果引入面向對象思想，并結合設計模式來重寫或改善我們的系統，那么我們的系統將會像目前一樣需要那么多人來維護嗎？

《大話設計模式》一書其實是對gof的《設計模式——可復用面向對象軟件的基礎》一書的“翻譯”，讓人更容易理解，用通俗易懂的語言闡述軟件設計過程中的一些“模式”，在某種特定環境

下，用最好的設計方法達到我們的目的，或許其方法有很多很多，但是尋找到最好的方法卻不是件容易的事，設計模式是對前人的設計經驗的一個總結，告訴我們在某種特定的環境下，這樣的設計師最好的，學習設計模式有助于我們在設計軟件的過程中少走很多彎路。

我對gof的23個設計模式雖然都有看過，但是只有理解，實現，應用及思考之后，才能真正體會其精妙之處，至今體會較深的有以下幾個模式：1.strategy——封裝系列“算法”，讓它們之間可以相互替換，“算法”并不是單指數據結構中的算法，在實踐中，它幾乎可以封裝任何類型的規則，這使得策略模式的運用極其廣泛；2.template method——有人說是用的做多的模式，只要有抽象類的地方，都可以看到這個模式，它通過把不變行為移到父類中去，去除子類中的重復代碼，從而提供了一個很好的代碼復用平臺；3.facade——提供了對基礎架構的統一訪問，減少復雜

性，在web編程者中的三層架構，就是此思想，每一層都封裝好一部分功能，提供給上一層統一的方法調用，整個framework體系就是facade模式的封裝，隨著1.0升級到3.5，越來越多復雜的高級功能被封裝，可以說facade無處不在；4.abstract factory——提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類，咋一看，太抽象了，說個例子，在三層架構中，bll層對dal層的調用會直接用到dal層中的類，如果dal層是分別對sql server，oracle的訪問，bll層需要根據實際情況決定實例化哪一個dal層中的類，我們又希望在兩種dal層切換時，bll層和ui層都不做改變，那么可在bll層和dal層中增加接口層和抽象工廠，讓它來實例化dal層中的實例；5.singleton——確保一個類僅有一個實例，并提供一個訪問它的全局訪問點，如單件窗體，點一下menu，彈出一個窗體，在關閉這個新窗體之前，再次點擊該menu，不會再次出現同樣的彈出窗

體。。篇幅有限，其他模式或多或少都有點感覺。

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

以前沒有接觸過設計模式，那其實也是因為以前沒有真正經歷過面向對象的設計。這樣的情況在我經歷了本科畢業設計，并且遵循我們實驗室的一位師兄的建議看了《設計模式精解》后有了根本的改變，我開始意識到一個程序員和一個設計者的區別，我也開始意識到在同學眼中“編程很強”的我只是——至少現在只是一個程序員。

我做的本科畢設是基于java-swing設計一個類似繪圖程序的系統，最終我

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

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

1．可重復性。解決方案應該對應于外部的場景。

2．可傳授性。一個解決方案應該可以移植到問題的不同情況中。

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

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

在前言中作者說在他對現有的設

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

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

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

2．規格視角。“只看軟件的接口，而不看實現”

3．實現視角。就是現在的我唯一使用的視角——置身于代碼之中。

看到這里我更加肯定了這本所講的是我從來沒有注意過的東西，但是我對這些東西應該非常感興趣，而我也深深地感慨：我為什么現在才看到這本書。

在書中作者回顧了它從前的一個設計，通過不斷修改得出的優秀設計，逐步展現出設計模式的強大威力。書中

有句話很經典——如果你只有一把錘子，那你會發現所有的東西都像釘子。意思是說如果你只知道一種解決問題的辦法，那你只會想用這個方法解決所有問題。我覺得這很像現在的我，在面向對象的設計中我幾乎只會“類繼承”，結果是我的畢設——過高的繼承體系導致緊耦合、低內聚。

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

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

在學過的幾種設計模式中，每一種設計模式都會有一種具體的應用場景，每一種場景描述的都是一種需求變化。

設計模式就是用來解決這些變化的。

只要客戶有新的需求，你的程序就要發生改變，不管你用什么方法，這個改變是避免不了的。關鍵是你如何是解決這種變化！設計模式就是尋求一種通用的較好的方法來解決這種變化而不是避免這種變化，并不是你應用了設計模式，你的系統就不會發生變化了。

面向對象的編程有三大機制，我個人認為，設計模式很好的利用了其中的“封裝與多態”，比如工廠方法模式和生成器模式?！胺庋b”的意義不僅僅在于封裝代碼的實現，更重要的是“封裝”系統中變化的部分。設計模式回答了怎么樣去“封裝”這種變化。

在一個系統中，總會有一部分經常發生變化，相對的，也總有一個部分是改變頻率較低的，我們可以在某種范圍內將其理解為不改變的部分。設計模式要作的事情就是把“變化”的部分封裝起來，實現將“變化”的部分與“不變化”的部隔離，這樣，“變化”的部分在發生變化

時，不會影響到“不改變”的部分。如果你也學過設計模式，那你可能跟我有同感。設計模式解決變化的途徑可以概括為兩步：一是轉移變化，二是轉化變化。

首先是“轉移變化”。

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

為什么要這樣回答，因為這個時候，你的系統可能已經交付用戶了，如果讓調用者發生變化，那整個系統都要發生變化。

然后是“轉化變化”。

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

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

以上文字完全是本人理解，隨著不

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

洋思模式心得體會

從學習杜郎口到學習洋思已經好幾年了，每年每學期都要進行大規模的聽課活動，可謂轟轟烈烈，但學習了好幾年時間，我心中仍然一塌糊涂，一知半解，難以靈活運用，嘗試著運用時，也是提襟見肘，顧此失彼。所以成功的經驗很少，只能有一點粗略的感受。

我覺得目標設計盡量的要簡潔明了，通俗易懂，要讓絕大多數學生能夠完成，如果太難或過于簡單，都不利于學生的學習。目標設計應控制在1----3條為宜，如果目標太多，一節課根本無法完成，那就白設計了，從學生的角度來說，當看到很多的目標時，心中會產生恐懼和排斥情緒，不利于學習。

由于條件限制，當堂訓練時只能采

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

其它環節，我正在努力嘗試、探索。

教學模式心得體會

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

一、改變舊觀念，接受新模式

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

二、把課堂還給學生

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

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

三、把課前的準備做充分

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

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

一、靠持續不斷的語言知識，而不是“玩”來培養學生持久的興趣初中英語教學是要重視培養興趣，但單靠唱歌游

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

當認真進行語言學習。

二、英語應用能力需要相應的詞匯。“不學習語言規則、不掌握相當數量的詞匯，英語應用能力就是空中樓閣”。目前在中學的低年級的英語教學中，不要求學生掌握詞匯，而只要求學生能根據提示或圖片說出該單詞，其本質無非是要學生們死記硬背，鸚鵡學舌。由于學生們沒有相應的讀音規則訓練，不熟

悉詞匯的拼寫規則，單詞的音、形、意三者不能有效的結合在一起，因而導致了單詞記憶的困難，并成了中學生學英語的瓶頸。

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

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

字多用”。

2、隨著現代科學技術的迅猛發展，現代英語詞匯急劇增加，并且我們發現，現代英語詞匯有相當一部分是取得新義的舊詞，如，“input”，“store”，“drive”等。

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

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

第五篇：設計模式心得體會[推薦]

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

三個月以來，總算把設計模式學完一遍了，原計劃是兩個月學完（一星期三個模式），由于。。計劃兩個月學完實際花了三個月，感觸多多，收獲多多——對c#語言有了更進一步的認識，對oo的思想有了更全面的了解。。

下一步在設計模式方面的計劃：鞏固并運用設計模式，鞏固：把《大話設計模式》，《設計模式》，《設計模式——可復用的面向對象基礎》，《敏捷軟件開發：原則、模式與實踐》這些書再結合起來系統的看一看，當然還會去買一些我手頭上沒有的關于設計模式的書；運用：部門前幾天也提倡用c#來改版vb程序，我想這是一個很好的平臺，正好有機會把理論的東西在實際中應用，理論加實際——唯一的學習方法。。

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

1、創建型模式：

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

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

factory method：創建單個對象，在abstract factory有使用到。

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

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

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

2、結構性模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正確對待模式：

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

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

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

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

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

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

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

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

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