設計模式課程設計報告

通過這次課程設計使我們都更加懂得並親身體會到了理論與實際相結合的重要性，只有理論知識是遠遠不夠的，只有把所學的理論知識與實踐相結合起來，從實踐中得出結論，才能真正為社會服務，從而提高自己的實際動手能力和獨立思考的能力。以下是小編整理的設計模式課程設計報告，歡迎閱讀。

一、問題要求及任務描述

設計模式課程作業要求獨立製作一個軟體，功能是實現23種模式的定義、優缺點以及顯示示例程式碼。

（一）、題目要求

設計軟體，將23種設計模式結合，要能夠顯示每種模式的定義、優缺點以及舉例說明例子，加上簡單的程式碼說明。

（二）、主要任務

主要是選擇一種工具，實現顯示的功能，整理各種模式的定義，概念、使用情況、以及選擇模式例項，程式碼實現；

（三）、典型例項實現（任選三個分屬於不同設計模式的例項）

1、單例模式 定義與結構

單例模式的意思就是隻有一個例項。單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項。這個類稱為單例類。 單例模式的要點

顯然單例模式的要點有三個；一是某個類只能有一個例項；二是它必須自行建立這個例項；三是它必須自行向整個系統提供這個例項。在下面的物件圖中，有一個單例物件，而客戶甲、客戶乙和客戶丙是單例物件的三個客戶物件。可以看到，所有的客戶物件共享一個單例物件。而且從單例物件到自身的連線線可以看出，單例物件持有對自己的引用。靜態變數(這是c/c++的叫法，其他語言或有不同)是實現單例模式的要素。 單例模式的2種方式：餓漢式，懶漢式

單例模式屬於物件建立型模式，其意圖是保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。對一些類來說，只有一個例項是很重要的，雖然系統中可以有許多印表機，但卻只應該有一個印表機假離線，只應該有一個檔案系統和一個視窗管理器，一個數字濾波器只能有一個A/D轉換器，一個會計系統只能專用於一個公司。怎樣才能保證一個類只有一個例項並且這個例項易於被訪問，一個全域性變數使得一個物件可以被訪問，但它不能防止你例項化多個物件，一個更好的方法是讓類自身負責儲存他的唯一例項。這個類可以保證沒有其他例項可以被建立，並且它可以提供一個訪問該例項的方法，這就是Singleton模式。

一個產生隨機數的例子，整個應用程式中只需要一個類的例項來產生隨機數，客戶端程式從類中獲取這個例項，呼叫這個例項的方法nextInt()，公用的方法訪問需要進行同步，這是單例模式需要解決的同步問題。

2、工廠方法模式 定義與結構

工廠方法模式的意義是定義一個建立產品物件的工廠介面，將實際建立工作推遲到子類當中。核心工廠類不再負責產品的建立，這樣核心類成為一個抽象工廠角色，僅負責具體工廠子類必須實現的介面，這樣進一步抽象化的好處是使得工廠方法模式可以使系統在不修改具體工廠角色的情況下引進新的產品。

工廠方法模式是簡單工廠模式的衍生，解決了許多簡單工廠模式的問題。首先完全實現‘開－閉 原則’，實現了可擴充套件。其次更復雜的層次結構，可以應用於產品結果複雜的場合。

工廠方法模式的對簡單工廠模式進行了抽象。有一個抽象的Factory類（可以是抽象類和介面），這個類將不在負責具體的產品生產，而是隻制定一些規範，具體的生產工作由其子類去完成。在這個模式中，工廠類和產品類往往可以依次對應。即一個抽象工廠對應一個抽象產品，一個具體工廠對應一個具體產品，這個具體的工廠就負責生產對應的產品。

適用情況

第一種情況是對於某個產品，呼叫者清楚地知道應該使用哪個具體工廠服務，例項化該具體工廠，生產出具體的產品來。Java Collection中的iterator() 方法即屬於這種情況。

第二種情況，只是需要一種產品，而不想知道也不需要知道究竟是哪個工廠為生產的，即最終選用哪個具體工廠的決定權在生產者一方，它們根據當前系統的情況來例項化一個具體的工廠返回給使用者，而這個決策過程這對於使用者來說是透明的。 優缺點

首先，良好的.封裝性，程式碼結構清晰。一個物件建立是有條件約束的，如一個呼叫者需要一個具體的產品物件，只要知道這個產品的類名（或約束字串）就可以了，不用知道建立物件的艱辛過程，減少模組間的耦合。

其次，工廠方法模式的擴充套件性非常優秀。在增加產品類的情況下，只要適當地修改具體的工廠類或擴充套件一個工廠類，就可以完成“擁抱變化”。例如在我們的例子中，需要增加一個棕色人種，則只需要增加一個BrownHuman類，工廠類不用任何修改就可完成系統擴充套件。 再次，遮蔽產品類。這一特點非常重要，產品類的實現如何變化，呼叫者都不需要關心，它只需要關心產品的介面，只要介面保持不表，系統中的上層模組就不要發生變化，因為產品類的例項化工作是由工廠類負責，一個產品物件具體由哪一個產品生成是由工廠類決定的。在資料庫開發中，大家應該能夠深刻體會到工廠方法模式的好處：如果使用JDBC連線資料庫，資料庫從MySql切換到Oracle，需要改動地方就是切換一下驅動名稱（前提條件是SQL語句是標準語句），其他的都不需要修改，這是工廠方法模式靈活性的一個直接案。 最後，工廠方法模式是典型的解耦框架。高層模組值需要知道產品的抽象類，其他的實現類都不用關心，符合迪米特原則，我不需要的就不要去交流；也符合依賴倒轉原則，只依賴產品類的抽象；當然也符合里氏替換原則，使用產品子類替換產品父類，沒問題！

3、備忘錄模式

定義與結構

備忘錄（Memento）模式又稱標記（Token）模式。GOF給備忘錄模式的定義為：在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。

從定義可以看出備忘錄模式是專門來存放物件歷史狀態的，這對於很好的實現undo、redo功能有很大的幫助。所以在命令模式中undo、redo功能可以配合備忘錄模式來實現。

適用情況

使用了備忘錄模式來實現儲存物件的歷史狀態可以有效地保持封裝邊界。使用備忘錄可以避免暴露一些只應由“備忘發起角色”管理卻又必須儲存在“備忘發起角色”之外的資訊。把“備忘發起角色”內部資訊對其他物件遮蔽起來, 從而保持了封裝邊界。

但是如果備份的“備忘發起角色”存在大量的資訊或者建立、恢復操作非常頻繁，則可能造成很大的開銷。

GOF在《設計模式》中總結了使用備忘錄模式的前提：

1) 必須儲存一個物件在某一個時刻的(部分)狀態, 這樣以後需要時它才能恢復到先前的狀態。

2) 如果一個用介面來讓其它物件直接得到這些狀態，將會暴露物件的實現細節並破壞物件的封裝性。 優缺點

優點：使用備忘錄模式，可以避免暴露一些只應由源發器管理卻又必須儲存在源發器之外的資訊，而且能夠在物件需要時恢復到先前的狀態。

缺點：使用備忘錄可能代價很高。如果源發器在生成備忘錄時必須複製並存儲大量的資訊，或者客戶非常頻繁地建立備忘錄和恢復源發器狀態，可能會導致非常大的開銷。

1)備忘錄（Memento）角色：備忘錄角色儲存“備忘發起角色”的內部狀態。“備忘發起角色”根據需要決定備忘錄角色儲存“備忘發起角色”的哪些內部狀態。為了防止“備忘發起角色”以外的其他物件訪問備忘錄。備忘錄實際上有兩個介面，“備忘錄管理者角色”只能看到備忘錄提供的窄介面——對於備忘錄角色中存放的屬性是不可見的。“備忘發起角色”則能夠看到一個寬介面——能夠得到自己放入備忘錄角色中屬性。

2)備忘發起（Originator）角色：“備忘發起角色”建立一個備忘錄，用以記錄當前時刻它的內部狀態。在需要時使用備忘錄恢復內部狀態。

3)備忘錄管理者（Caretaker）角色：負責儲存好備忘錄。不能對備忘錄的內容進行操作或檢查。

三、小結

（一）、問題解決方法及程式實現小結

我的課程設計作業用的是Dreamever，即靜態網頁。因為本身每種模式的內容相對固定，例項程式碼以及uml圖片都不會有很大的變動，而且所有模式所涉及的資料內容不多，不需要資料庫支援，所以用靜態網頁形式顯示既方便又合理。

在製作網頁的過程中，開始的思路是運用浮動框架，但是因為每種模式程式碼普遍比較多，若顯示與框架之內，整個頁面佈局不夠合理，也不美觀，於是，一種模式運用兩個頁面來顯示，即合理又美觀。

但是軟體也有本身的缺陷，內容相對固定，不易改變，在變動後不容易改變。從每個頁面迴歸前一個頁面的時候可能會不方便。

學習設計模式讓我們感覺程式設計實際上是一件很有意思的事情，23種設計模式，每種模式又有自己獨特的解決思路，帶有一定的通用性。我們在發現問題到解決問題這個過程中，常會發現很多問題是重複出現的，或是某個問題的變體，外在不同，而本質相同，這些問題的本質就是模式。設計模式主要是在大量變成的基礎上加以總結，以減少重複編碼。

（二）、 尚未解決的問題及下一步工作思路

對於模板方法模式的理解還不夠，相關內容還沒有找到，對於課本上c#理解還不夠深入，應該學習用多種語言實現每種模式，理解其基本思想。

（三）、 收穫

在本次課程設計中，加深了對於23種設計模式的理解和記憶，更加明白總結對於學習的重要性，在程式開發中，重複性的東西是對於資源的一種浪費，所以在以後學習中應該在更加註重總結學習。本次的課程設計作業也能作為以後學習的一個工具，在需要複習的時候，可以回來查閱總結的內容，一舉兩得。