品才網(wǎng)>輔助設計與工程計算>設計模式課程設計報告

設計模式課程設計報告

時間：2022-07-03 02:31:00 輔助設計與工程計算我要投稿

相關推薦

設計模式課程設計報告

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

設計模式課程設計報告

　　一、問題要求及任務描述

　　設計模式課程作業(yè)要求獨立制作一個軟件，功能是實現(xiàn)23種模式的定義、優(yōu)缺點以及顯示示例代碼。

　�。ㄒ唬㈩}目要求

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

　　（二）、主要任務

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

　�。ㄈ�、典型實例實現(xiàn)（任選三個分屬于不同設計模式的實例）

　　1、單例模式定義與結構

　　單例模式的意思就是只有一個實例。單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例。這個類稱為單例類。單例模式的要點

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

　　單例模式屬于對象創(chuàng)建型模式，其意圖是保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。對一些類來說，只有一個實例是很重要的，雖然系統(tǒng)中可以有許多打印機，但卻只應該有一個打印機假脫機，只應該有一個文件系統(tǒng)和一個窗口管理器，一個數(shù)字濾波器只能有一個A/D轉換器，一個會計系統(tǒng)只能專用于一個公司。怎樣才能保證一個類只有一個實例并且這個實例易于被訪問，一個全局變量使得一個對象可以被訪問，但它不能防止你實例化多個對象，一個更好的方法是讓類自身負責保存他的唯一實例。這個類可以保證沒有其他實例可以被創(chuàng)建，并且它可以提供一個訪問該實例的方法，這就是Singleton模式。

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

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

　　工廠方法模式的意義是定義一個創(chuàng)建產(chǎn)品對象的工廠接口，將實際創(chuàng)建工作推遲到子類當中。核心工廠類不再負責產(chǎn)品的創(chuàng)建，這樣核心類成為一個抽象工廠角色，僅負責具體工廠子類必須實現(xiàn)的接口，這樣進一步抽象化的好處是使得工廠方法模式可以使系統(tǒng)在不修改具體工廠角色的情況下引進新的產(chǎn)品。

　　工廠方法模式是簡單工廠模式的衍生，解決了許多簡單工廠模式的問題。首先完全實現(xiàn)‘開－閉原則’，實現(xiàn)了可擴展。其次更復雜的層次結構，可以應用于產(chǎn)品結果復雜的場合。

　　工廠方法模式的對簡單工廠模式進行了抽象。有一個抽象的Factory類（可以是抽象類和接口），這個類將不在負責具體的產(chǎn)品生產(chǎn)，而是只制定一些規(guī)范，具體的生產(chǎn)工作由其子類去完成。在這個模式中，工廠類和產(chǎn)品類往往可以依次對應。即一個抽象工廠對應一個抽象產(chǎn)品，一個具體工廠對應一個具體產(chǎn)品，這個具體的工廠就負責生產(chǎn)對應的產(chǎn)品。

　　適用情況

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

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

　　首先，良好的封裝性，代碼結構清晰。一個對象創(chuàng)建是有條件約束的，如一個調用者需要一個具體的產(chǎn)品對象，只要知道這個產(chǎn)品的類名（或約束字符串）就可以了，不用知道創(chuàng)建對象的艱辛過程，減少模塊間的耦合。

　　其次，工廠方法模式的擴展性非常優(yōu)秀。在增加產(chǎn)品類的情況下，只要適當?shù)匦薷木唧w的工廠類或擴展一個工廠類，就可以完成“擁抱變化”。例如在我們的例子中，需要增加一個棕色人種，則只需要增加一個BrownHuman類，工廠類不用任何修改就可完成系統(tǒng)擴展。再次，屏蔽產(chǎn)品類。這一特點非常重要，產(chǎn)品類的實現(xiàn)如何變化，調用者都不需要關心，它只需要關心產(chǎn)品的接口，只要接口保持不表，系統(tǒng)中的上層模塊就不要發(fā)生變化，因為產(chǎn)品類的實例化工作是由工廠類負責，一個產(chǎn)品對象具體由哪一個產(chǎn)品生成是由工廠類決定的。在數(shù)據(jù)庫開發(fā)中，大家應該能夠深刻體會到工廠方法模式的好處：如果使用JDBC連接數(shù)據(jù)庫，數(shù)據(jù)庫從MySql切換到Oracle，需要改動地方就是切換一下驅動名稱（前提條件是SQL語句是標準語句），其他的都不需要修改，這是工廠方法模式靈活性的一個直接案。最后，工廠方法模式是典型的解耦框架。高層模塊值需要知道產(chǎn)品的抽象類，其他的實現(xiàn)類都不用關心，符合迪米特原則，我不需要的就不要去交流；也符合依賴倒轉原則，只依賴產(chǎn)品類的抽象；當然也符合里氏替換原則，使用產(chǎn)品子類替換產(chǎn)品父類，沒問題！

　　3、備忘錄模式

　　定義與結構

　　備忘錄（Memento）模式又稱標記（Token）模式。GOF給備忘錄模式的定義為：在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復到原先保存的狀態(tài)。

　　從定義可以看出備忘錄模式是專門來存放對象歷史狀態(tài)的，這對于很好的實現(xiàn)undo、redo功能有很大的幫助。所以在命令模式中undo、redo功能可以配合備忘錄模式來實現(xiàn)。

　　適用情況

　　使用了備忘錄模式來實現(xiàn)保存對象的歷史狀態(tài)可以有效地保持封裝邊界。使用備忘錄可以避免暴露一些只應由“備忘發(fā)起角色”管理卻又必須存儲在“備忘發(fā)起角色”之外的信息。把“備忘發(fā)起角色”內(nèi)部信息對其他對象屏蔽起來, 從而保持了封裝邊界。

　　但是如果備份的“備忘發(fā)起角色”存在大量的信息或者創(chuàng)建、恢復操作非常頻繁，則可能造成很大的開銷。

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

　　1) 必須保存一個對象在某一個時刻的(部分)狀態(tài), 這樣以后需要時它才能恢復到先前的狀態(tài)。

　　2) 如果一個用接口來讓其它對象直接得到這些狀態(tài)，將會暴露對象的實現(xiàn)細節(jié)并破壞對象的封裝性。優(yōu)缺點

　　優(yōu)點：使用備忘錄模式，可以避免暴露一些只應由源發(fā)器管理卻又必須存儲在源發(fā)器之外的信息，而且能夠在對象需要時恢復到先前的狀態(tài)。

　　缺點：使用備忘錄可能代價很高。如果源發(fā)器在生成備忘錄時必須復制并存儲大量的信息，或者客戶非常頻繁地創(chuàng)建備忘錄和恢復源發(fā)器狀態(tài)，可能會導致非常大的開銷。

　　1)備忘錄（Memento）角色：備忘錄角色存儲“備忘發(fā)起角色”的內(nèi)部狀態(tài)�！皞渫l(fā)起角色”根據(jù)需要決定備忘錄角色存儲“備忘發(fā)起角色”的哪些內(nèi)部狀態(tài)。為了防止“備忘發(fā)起角色”以外的其他對象訪問備忘錄。備忘錄實際上有兩個接口，“備忘錄管理者角色”只能看到備忘錄提供的窄接口——對于備忘錄角色中存放的屬性是不可見的�！皞渫l(fā)起角色”則能夠看到一個寬接口——能夠得到自己放入備忘錄角色中屬性。

　　2)備忘發(fā)起（Originator）角色：“備忘發(fā)起角色”創(chuàng)建一個備忘錄，用以記錄當前時刻它的內(nèi)部狀態(tài)。在需要時使用備忘錄恢復內(nèi)部狀態(tài)。

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

　　三、小結

　�。ㄒ唬栴}解決方法及程序實現(xiàn)小結

　　我的課程設計作業(yè)用的是Dreamever，即靜態(tài)網(wǎng)頁。因為本身每種模式的內(nèi)容相對固定，實例代碼以及uml圖片都不會有很大的變動，而且所有模式所涉及的數(shù)據(jù)內(nèi)容不多，不需要數(shù)據(jù)庫支持，所以用靜態(tài)網(wǎng)頁形式顯示既方便又合理。

　　在制作網(wǎng)頁的過程中，開始的思路是運用浮動框架，但是因為每種模式代碼普遍比較多，若顯示與框架之內(nèi)，整個頁面布局不夠合理，也不美觀，于是，一種模式運用兩個頁面來顯示，即合理又美觀。

　　但是軟件也有本身的缺陷，內(nèi)容相對固定，不易改變，在變動后不容易改變。從每個頁面回歸前一個頁面的時候可能會不方便。

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

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

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

　�。ㄈ�、收獲

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

【設計模式課程設計報告】相關文章：

課程設計報告07-23

課程設計報告09-11

翻轉課堂模式應用文寫作課程設計探索論文07-03

關于系統(tǒng)的課程設計報告08-05