軟件設計模式實驗報告_第1頁
軟件設計模式實驗報告_第2頁
軟件設計模式實驗報告_第3頁
軟件設計模式實驗報告_第4頁
軟件設計模式實驗報告_第5頁
已閱讀5頁,還剩26頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、 計算機科學與技術學院 實 驗 報 告課程名稱: 軟件設計模式 專 業(yè): 計算機科學與技術 班 級: 2011 級 1 班 學 號: 201113137040 姓 名: 劉進平 實驗一 單例模式的應用1 實驗目的1) 掌握單例模式(Singleton)的特點2) 分析具體問題,使用單例模式進行設計。2 實驗內(nèi)容和要求很多應用項目都有配置文件,這些配置文件里面定義一些應用需要的參數(shù)數(shù)據(jù)。 通??蛻舳耸褂眠@個類是通過new一個AppConfig的實例來得到一個操作配置文件內(nèi)容的對象。如果在系統(tǒng)運行中,有很多地方都需要使用配置文件的內(nèi)容,系統(tǒng)中會同時存在多份配置文件的內(nèi)容,這會嚴重浪費內(nèi)存資源。事實

2、上,對于AppConfig類,在運行期間,只需要一個對象實例就夠了。那么應該怎么實現(xiàn)呢?用C#控制臺應用程序實現(xiàn)該單例模式。繪制該模式的UML圖。UML圖: 源代碼: class Program static void Main(string args) AppConfig appConfigOne = AppConfig.GetParameterA(); AppConfig appConfigTwo = AppConfig.GetParameterA(); if (appConfigOne.Equals(appConfigTwo) Console.WriteLine("appCon

3、figOne 和 appConfigTwo 代表的是同一個實例!"); else Console.WriteLine("appConfigOne 和 appConfigTwo 代表的是不同的實例!"); Console.ReadKey(); 運行結果:實驗小結:通過這次實驗,我了解了單例模式的具體概念和使用方法,并且感受到了他的優(yōu)點帶來的方便,但是同時也知道了該設計模式的缺點:由于單例模式中沒有抽象層,因此單例類的擴展有很大困難。 實驗二 工廠模式的應用1 實驗目的1) 掌握工廠模式(Factory)的特點2) 分析具體問題,使用工廠模式進行設計。2 實驗內(nèi)容和要

4、求有一個OEM制造商代理做HP筆記本電腦(Laptop),后來該制造商得到了更多的品牌筆記本電腦的訂單Acer,Lenovo,Dell,該OEM商發(fā)現(xiàn),如果一次同時做很多個牌子的本本,有些不利于管理。利用工廠模式改善設計,用C#控制臺應用程序實現(xiàn)該OEM制造商的工廠模式。繪制該模式的UML圖。UML圖:源代碼: class Laptop public virtual void GetLaptop() class HpLaptop:Laptop public override void GetLaptop() Console.WriteLine("生產(chǎn)了一臺Hp電腦"); c

5、lass AcerLaptop : Laptop public override void GetLaptop() Console.WriteLine("生產(chǎn)了一臺Acer電腦"); class LenovoLaptop : Laptop public override void GetLaptop() Console.WriteLine("生產(chǎn)了一臺Lenovo電腦"); class DellLaptop : Laptop public override void GetLaptop() Console.WriteLine("生產(chǎn)了一臺Del

6、l電腦"); interface IFactory Laptop CreateFactory(); class HpFactory:IFactory public Laptop CreateFactory() return new HpLaptop(); class AcerFactory : IFactory public Laptop CreateFactory() return new AcerLaptop(); class LenovoFactory : IFactory public Laptop CreateFactory() return new LenovoLapto

7、p(); class DellFactory : IFactory public Laptop CreateFactory() return new DellLaptop(); class Program static void Main(string args) IFactory laptopFactory = new LenovoFactory(); IFactory laptopFactory1 = new HpFactory(); IFactory laptopFactory2 = new AcerFactory(); IFactory laptopFactory3 = new Del

8、lFactory(); Laptop laptop = laptopFactory.CreateFactory(); Laptop laptop1 = laptopFactory1.CreateFactory(); Laptop laptop2 = laptopFactory2.CreateFactory(); Laptop laptop3 = laptopFactory3.CreateFactory(); laptop.GetLaptop(); laptop1.GetLaptop(); laptop2.GetLaptop(); laptop3.GetLaptop(); Console.Rea

9、dKey(); 運行結果:實驗小結:通過本次實驗,我了解了工廠模式的適用范圍和他的一些特點,工廠模式在一定程度上解決某些代碼違反了面向對象設計的開放封閉原則。同時還了解了它的一些優(yōu)點和弊端,比如:使用工廠方法模式的另一個優(yōu)點是在系統(tǒng)中加入新產(chǎn)品時,無需修改抽象工廠和抽象產(chǎn)品提供的接口,無需修改客戶端,也無需修改其它的具體工廠和具體產(chǎn)品,而只要添加一個新的具體工廠和具體產(chǎn)品即可。實驗三 抽象工廠模式的應用1 實驗目的1) 掌握抽象工廠模式(Abstract Factory)的特點2) 分析具體問題,使用抽象工廠模式進行設計。2 實驗內(nèi)容和要求麥當勞(McDonalds)和肯德基(KFC)快餐店都

10、經(jīng)營漢堡(Hamburg)和可樂(Cola),用C#控制臺應用程序實現(xiàn)這兩個快餐店經(jīng)營產(chǎn)品的抽象工廠模式。繪制該模式的UML圖。UML圖:源代碼: interface IHamburg void HamburgName(); class McDonaldsHamburg : IHamburg public void HamburgName() Console.WriteLine("這是McDonalds Hamburg"); class KFCHamburg : IHamburg public void HamburgName() Console.WriteLine(&qu

11、ot;這是KFC Hamburg"); interface ICola void ColaName(); class McDonaldsCola : ICola public void ColaName() Console.WriteLine("這是McDonalds Cola"); class KFCCola : ICola public void ColaName() Console.WriteLine("這是KFC Cola"); interface IFactory IHamburg CreateHamburg(); ICola Cre

12、ateCola(); class McDonaldsFactory : IFactory public IHamburg CreateHamburg() return new McDonaldsHamburg(); public ICola CreateCola() return new McDonaldsCola(); class KFCFactory : IFactory public IHamburg CreateHamburg() return new KFCHamburg(); public ICola CreateCola() return new KFCCola(); class

13、 Program static void Main(string args) IFactory factory = new KFCFactory(); IFactory factory1 = new McDonaldsFactory(); IHamburg hamburg1 = factory1.CreateHamburg(); ICola cola1 = factory1.CreateCola(); IHamburg hamburg = factory.CreateHamburg(); ICola cola = factory.CreateCola(); hamburg.HamburgNam

14、e(); cola.ColaName(); hamburg1.HamburgName(); cola1.ColaName(); Console.ReadKey(); 運行結果:實驗小結:通過本次實驗,加深了對抽象工廠模式的理解。抽象工廠提供一個創(chuàng)建一系列相關或相互依賴對象的接口,而不需指定他們具體的類。抽象工廠同樣是存在缺點的,難以支持新種類的產(chǎn)品。  由于以前對C+不太了解,本次實驗加深了對C+的了解,強化了編程能力。理解解了構造函數(shù),虛函數(shù),純虛函數(shù),成員函數(shù)實現(xiàn),類之間的繼承等含義。 但對于函數(shù)的調(diào)用問題常常出錯,這在以后的學習中應多加注意和練習。實驗四 建

15、造者模式的應用1 實驗目的1) 掌握建造者模式(Builder)的特點2) 分析具體問題,使用建造者模式進行設計。2 實驗內(nèi)容和要求建造者模式是一種創(chuàng)建型模式,它主要是應對項目中一些復雜對象的創(chuàng)建工作。所謂“復雜對象”,是指此對象中還含有其它的子對象。我們現(xiàn)在定義一個場景:汽車生產(chǎn)必須包含車輪(Wheel)、油箱(OilBox)和車身(Body),應用建造者模式,用C#控制臺應用程序實現(xiàn)該設計,構建BMW品牌和BenZ品牌汽車生產(chǎn)。繪制該模式的UML圖。UML圖:源代碼: public abstract class ICar public abstract void Wheel(); publ

16、ic abstract void OilBox(); public abstract void Body(); class Benz:ICar public override void Wheel() Console.Write("奔馳的輪子,"); public override void OilBox() Console.Write("奔馳的油箱,"); public override void Body() Console.WriteLine("奔馳的車體!"); class BMW:ICar public override v

17、oid Wheel() Console.Write("寶馬的輪子,"); public override void OilBox() Console.Write("寶馬的油箱,"); public override void Body() Console.WriteLine("寶馬的車體!"); class Driver public void include(ICar car) car.Wheel(); car.OilBox(); car.Body(); class Program static void Main(string a

18、rgs) ICar car = new Benz(); ICar car1 = new BMW(); Driver zhangsan = new Driver(); zhangsan.include(car); Driver lisi = new Driver(); lisi.include(car1); Console.ReadKey(); 運行結果:實驗小結:建造者模式的設計目的是消除其他對象的復雜創(chuàng)建過程。使用建造者模式不僅是最佳的做法,而且在某個對象的構建和配制方法改變時可以盡量減少重復更改代碼實驗五 適配器模式的應用1 實驗目的1) 掌握適配器模式(Adapter)的特點2) 分析具

19、體問題,使用適配器模式進行設計。2 實驗內(nèi)容和要求一個軟件團隊開發(fā)繪圖系統(tǒng),設計了圓對象(Circle)、矩形對象(Rectangle),線對象(Line)都支持Draw()函數(shù),即可以通過Draw()函數(shù)繪制圖形。為了加快項目進度,將角度對象(Angle)繪制功能交給了合作團隊實現(xiàn)。但合作團隊將角度對象繪制函數(shù)定為了DrawAngle()。繪圖系統(tǒng)提供給用戶后,用戶不滿意,希望能統(tǒng)一的調(diào)用,不用記太多命令。應用適配器模式,用C#控制臺應用程序完善該設計。繪制該模式的UML圖。UML圖:源代碼: abstract class IDrawing public abstract void Draw

20、(); class Circle : IDrawing public override void Draw() Console.WriteLine("這是Circle里面的Draw方法"); class Rectangle : IDrawing public override void Draw() Console.WriteLine("這是Rectangle里面的Draw方法"); class Line : IDrawing public override void Draw() Console.WriteLine("這是Line里面的Dra

21、w方法"); class Angle public void DrawAngle() Console.WriteLine("這是Angle里面的DrawAngle方法"); class AdapterAngle : IDrawing private Angle ag = new Angle(); public override void Draw() ag.DrawAngle(); class Program static void Main(string args) IDrawing cc = new Circle(); cc.Draw(); IDrawing

22、rr = new Rectangle(); rr.Draw(); IDrawing ll = new Line(); ll.Draw(); IDrawing aa = new AdapterAngle(); aa.Draw(); Console.ReadKey(); 運行結果:實驗小結:適配器模式可以讓任何兩個沒有關聯(lián)的類一起運行,提高了類的復用,增加了類的透明度 ,靈活性好,但是過多的使用適配器,會讓系統(tǒng)非常零亂,不易整體進行把握。比如,明明看到調(diào)用的是A接口,其實內(nèi)部被適配成了B接口的實現(xiàn),一個系統(tǒng)如果太多出現(xiàn)這種情況,無異于一場災難。因此如果不是很有必要,可以不使用適配器,而是直接對系統(tǒng)

23、進行重構。由于JAVA至多繼承一個類,所以至多只能適配一個適配者類,而且目標類必須是抽象類。實驗六 橋接模式的應用1 實驗目的1) 掌握橋接模式(Bridge)的特點2) 分析具體問題,使用橋接模式進行設計。2 實驗內(nèi)容和要求一個咖啡店可以提供大杯(JorumCoffee)、中杯(MediumCoffee)、小杯(SmallCoffee)的咖啡(Coffee),為了滿足不同用戶的口味,在咖啡中可以添加牛奶(Milk),或者糖(Sugar),或者檸檬(Lemon),提供給用戶不同口味的組合,如大杯咖啡加牛奶,中杯咖啡加糖,小杯咖啡加檸檬,小杯咖啡加糖等。應用橋接模式,用C#控制臺應用程序實現(xiàn)該設

24、計。繪制該模式的UML圖。UML圖:源代碼: abstract class Sauce public abstract void Mixing(); class Milk : Sauce public override void Mixing() Console.WriteLine("加牛奶"); class Sugar : Sauce public override void Mixing() Console.WriteLine("加糖"); class Lemon : Sauce public override void Mixing() Conso

25、le.WriteLine("加檸檬"); abstract class Coffee protected Sauce sauce; public void AddSauce(Sauce sauce) this.sauce = sauce; public abstract void Mixing(); class JorumCoffee : Coffee public override void Mixing() Console.Write("大杯咖啡"); sauce.Mixing(); class MediumCoffee : Coffee publi

26、c override void Mixing() Console.Write("中杯咖啡"); sauce.Mixing(); class SmallCoffee : Coffee public override void Mixing() Console.Write("小杯咖啡"); sauce.Mixing(); class Program static void Main(string args) /中杯咖啡加牛奶 Coffee coffeeOne = new MediumCoffee(); coffeeOne.AddSauce(new Milk(

27、); coffeeOne.Mixing(); /大杯咖啡加糖 Coffee coffeeTwo = new JorumCoffee(); coffeeTwo.AddSauce(new Sugar(); coffeeTwo.Mixing(); /小杯咖啡加糖 Coffee coffeeThree = new SmallCoffee(); coffeeThree.AddSauce(new Lemon(); coffeeThree.Mixing(); Console.ReadKey(); 運行結果:實驗小結:Bridge模式是一個非常有用的模式,也非常復雜,它很好的符合了開放-封閉原則和優(yōu)先使用對象

28、,而不是繼承這兩個面向對象原則。該模式使用“對象間的組合關系”解耦了抽象和實現(xiàn)之間固有的綁定關系,使得抽象和實現(xiàn)可以沿著各自的維度來變化。實驗七 裝飾模式的應用1 實驗目的1) 掌握裝飾模式(Decorator)的特點2) 分析具體問題,使用裝飾模式進行設計。2 實驗內(nèi)容和要求“喜羊羊逃命”游戲:喜羊羊被灰太狼追,喜羊羊最多5條命,灰太狼每咬到喜羊羊一次,喜羊羊就要少一條命。在逃的過程中喜羊羊可以吃到三種蘋果,吃“紅蘋果”可以給喜羊羊加上保護罩,吃“綠蘋果”可以加快喜羊羊奔跑速度,吃“黃蘋果”可以使喜羊羊趟著水跑。應用裝飾模式,用C#控制臺應用程序實現(xiàn)該設計。繪制該模式的UML圖。UML圖:源

29、代碼: abstract class State public abstract void Show(); class Animal : State private string name; public Animal(string name) = name; public override void Show() Console.WriteLine("的0", name); abstract class Apple:State protected State component; public void Decorator(State componen

30、t) ponent = component; public override void Show() if (component != null) component.Show(); class ProtectiveCover : Apple public override void Show() /base.Show(); Console.Write("有保護罩"); base.Show(); class RunFast : Apple public override void Show() /base.Show(); Console.Write("跑得快、&q

31、uot;); base.Show(); class FlowingWater : Apple public override void Show() /base.Show(); Console.Write("會趟水、"); base.Show(); class Program static void Main(string args) Animal pleasantsheep = new Animal("喜羊羊"); ProtectiveCover pc = new ProtectiveCover(); RunFast rf = new RunFast(

32、); FlowingWater fw = new FlowingWater(); pc.Decorator(pleasantsheep); rf.Decorator(pc); fw.Decorator(rf); fw.Show(); Console.ReadKey(); 運行結果:實驗小結:Decorator模式采用對象組合而非繼承的手法,實現(xiàn)了在運行時動態(tài)的擴展對象功能的能力,而且可以根據(jù)需要擴展多個功能,避免了單獨使用繼承帶來的“靈活性差”和“多子類衍生問題”。同時它很好地符合面向對象設計原則中“優(yōu)先使用對象組合而非繼承”和“開放-封閉”原則。實驗八 外觀模式的應用1 實驗目的1) 掌握外

33、觀模式(Facade)的特點2) 分析具體問題,使用外觀模式進行設計。2 實驗內(nèi)容和要求一個保安系統(tǒng)的,由錄像機、電燈、紅外線監(jiān)控和警報器組成。保安系統(tǒng)的操作人員需要經(jīng)常將這些儀器啟動和關閉。保安類需要用到所有的錄像機(Camera)、電燈(Light)、感應器(Sensor)和警報器(Alarm)對象,保安覺得使用不方便。應用外觀模式,用C#控制臺應用程序改進該設計。繪制該模式的UML圖。UML圖:源代碼: public class Camera public void TurnOn() Console.WriteLine("Turning on the

34、0;camera."); public void TurnOff() Console.WriteLine("Turning off the camera."); public void Rotate(int degrees) Console.WriteLine("Rotating the camera by 0 degrees.", degrees); public class Light public void TurnOff() Console.WriteLin

35、e("Turning on the light."); public void TurnOn() Console.WriteLine("Turning off the light."); public void ChangeBulb() Console.WriteLine("changing the light-bulb."); public class Sensor public void Activate() Console.WriteLine(&qu

36、ot;Activating the sensor."); public void Deactivate() Console.WriteLine("Deactivating the sensor."); public void Trigger() Console.WriteLine("The sensor has triggered."); public class Alarm public void Activate() Console.WriteLine("Act

37、ivating the alarm."); public void Deactivate() Console.WriteLine("Deactivating the alarm."); public void Ring() Console.WriteLine("Ringing the alarm."); public void StopRing() Console.WriteLine("Stop the alarm."); public clas

38、s SecurityFacade private static Camera camera1, camera2; private static Light light1, light2, light3; private static Sensor sensor; private static Alarm alarm; static SecurityFacade() camera1 = new Camera(); camera2 = new Camera(); light1 = new Light(); light2 = new Light(); light3 = new Light(); se

39、nsor = new Sensor(); alarm = new Alarm(); public void Activate() camera1.TurnOn(); camera2.TurnOn(); light1.TurnOn(); light2.TurnOn(); light3.TurnOn(); sensor.Activate(); alarm.Activate(); public void Deactivate() camera1.TurnOff(); camera2.TurnOff(); light1.TurnOff(); light2.TurnOff(); light3.TurnO

40、ff(); sensor.Deactivate(); alarm.Deactivate(); class Program static void Main(string args) SecurityFacade security;_ security = new SecurityFacade();_ security.Activate();_ Console.WriteLine("n-n");_ security.Deactivate(); Console.ReadKey(); 運行結果:實驗小結:Façade模式注重的是簡

41、化接口,它更多的時候是從架構的層次去看整個系統(tǒng),而并非單個類的層次。該模式對客戶屏蔽了子系統(tǒng)組件,因而減少了客戶處理的對象的數(shù)目并使得子系統(tǒng)使用起來更加方便。實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關系,而子系統(tǒng)內(nèi)部的功能組件往往是緊耦合的。松耦合關系使得子系統(tǒng)的組件變化不會影響到它的客戶。實驗九 觀察者模式的應用1 實驗目的1) 掌握外觀模式(Observer)的特點2) 分析具體問題,使用外觀模式進行設計。2 實驗內(nèi)容和要求網(wǎng)上商店中如果商品(product)在名稱(name)、價格(price)等方面有變化,系統(tǒng)能自動通知會員,將是網(wǎng)上商店區(qū)別傳統(tǒng)商店的一大特色。如何設計實現(xiàn)? 說明你所選擇的設計模式,畫出類關系圖并指明各個類的角色。應用外觀模式,用C#控制臺應用程序改進該設

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論