设计模式课程设计.doc

《设计模式课程设计.doc》由会员分享，可在线阅读，更多相关《设计模式课程设计.doc（17页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、苏州科技学院电子与信息工程学院课程设计报告书课程名称： 软件体系结构设计 班 级： 计算机0911班 学 号： 0920107105 姓 名： 钱 青 指导教师： 倪启东 二一一年十二月 说明：1.本文档是以DragonQuest小游戏为例，进行设计分析的。2.本文档所有类图都是采用UML的Class Diagram(在Rotional Rose2003下绘制)3.代码都是用C#编写。一、 需求分析1、 游戏概述DragonQuest是一个角色扮演类游戏(RPG)，该游戏实现的具体功能是设计两种类型的人物，分别为被玩家所控制的玩家人物(Hero)和由系统所控制的外部人物(Enemy)，游戏中的

2、主要情节就是Hero与 Enemy之间的战斗，双方互相发射子弹击打对方。 在游戏的设计中要求游戏具有良好的扩展性，游戏界面友好，应方便用户，游戏画面要尽可能直观、美观。游戏角色参考图片:玩家人物Hero敌人1EnemyBoss 敌人2EnemyOne敌人3EnemyTwo敌人4EnemyThree游戏战斗场面:2、 需求描述本游戏名为“DragonQuest”游戏，基本可以实现以下功能:1. 开始游戏2. 退出（分保存进度设置和不保存进度设置两种）3. 属性设置（开始的时候，对各属性值进行初始化操作）4. 清除玩家信息，保存进度对人物，环境的要求如下：1. 人物：游戏中分为两种角色，Hero和

3、 Enemy，两者都有对应的生命值，在所有的Enemy之中，有一个EnemyBoss,他在Enemy之中是最厉害的角色，该游戏中，Hero和EnemyBoss各只有一个，但是其他的Enemy可以有很多个，双方在战斗的过程中，双方的生命值会减少，当EnemyBoss的生命值为0时，游戏胜利，当Hero的生命值为0时，战斗失败，游戏结束。2. 环境：由于游戏规模的限制，游戏中环境的设置比较单一，整个游戏只在一个环境中进行。3. 人物移动：Enemy人物的移动是随机的，每隔一段时间，移动到一个地方，Hero的移动由玩家控制。4. 人物遭遇战：在游戏过程中，Hero和 Enemy相互发射子弹，当子弹打

4、到某个角色时，对应的角色的生命值就会降低，直到生命值为0，该角色死亡。此游戏分为用户和管理员：用户的主要操作：1、 未注册之前的准备2、 注册之后：A 登陆自己的账号，填写密码等信息，读取游戏进度B 开始游戏C 退出游戏D 保存进度 管理员的主要操作：1. 管理注册游戏的玩家信息2. 删除不保存的用户的信息，只保存相应的用户名3、 功能需求： 本游戏的主要功能有：1. 开始游戏2. 退出（分保存进度设置和不保存进度设置两种）3. 属性设置（开始的时候，对各属性值进行初始化操作）4. 清除玩家信息，在各地各种环境下保存进度4、 性能需求：所有操作都应在30ms内得到响应。本游戏主要运行在Wind

5、ows平台上，但以后有可能会扩展到其他平台，服务器数据库选用Mysql。5、 运行需求： 游戏中界面以客户端程序的方式显示，界面能做到简洁，美观，大方，与用户交互友好 。若程序中有微小的错误从而导致游戏的死机，请将信息及时汇报给我们，以便于我们及时的进行修改并完善。 用户忘记账号或者密码，可以通过游戏的说明书上的联系电话来联系管理员，根据注册的数据来判断账号的所属者，从而为用户提供服务。 用户不能运行游戏，则可能是用户的电脑配置太低不适合游戏，可更换电脑的配置来满足游戏所运行环境下的条件。 网络不通，排除故障后需要重新进入系统，系统不保存在用户进行游戏前的临时数据。 在游戏过程中服务器死机，可

6、在重启服务器后再统计一次即可。但不保存上次的临时数据。6、 其他需求： 对该软件的灵活性的要求，即当需求发生某些变化时，该游戏应该能应对如下变化，如： a操作方式上的变化； b运行环境的变化； c精度和有效时限的变化；d计划的变化或改进。 二、 游戏中角色的层次框架：三、 DragonQuest的设计主要包含了以下几种设计模式：1. 单件模式2. 工厂方法模式3. 策略模式4. 观察者模式5. 外观模式6. 代理模式四、 游戏设计中的模式的详细说明(一) 单件模式A. 设计说明 游戏中由于角色，元素比较多，在DragonQuest游戏中设计了一个HitCheck类，该类负责控制游戏中所有元素(

7、角色)，包括对角色的增加，删除和控制其各种行为，该类在整个游戏中只有一个实例，这里就可以用到单件模式，如果该类可以被实例化多次，那么游戏就会相当混乱，整个游戏就会失去控制，所以该类只能有一个实例，并且该类提供了一个全局的访问点。该类利用一个私有静态变量来记录HitCheck类的唯一实例私有构造函数private HitCheck()确保该类在类外是无法实例化的，只能在类内进行实例化。利用静态方法GetInstance()实例化对象，并返回这个实例。B. 类图C. 单件模式的实现代码public class HitCheck private static volatile HitCheck in

8、stance;/记录该类唯一的实例 private HitCheck() /私有构造函数public static HitCheck GetInstance()/实例化对象 if (instance = null) instance = new HitCheck(); return instance; (二) 工厂方法模式A. 设计说明游戏中涉及角色较多，每个角色都有自己的子弹，这样就可以用到工厂方法模式，这会使系统具有良好的扩展性和可维护性，达到一种松耦合的目的，以便将代码从具体类解耦，游戏中有两个抽象类Roles和Missiles分别作为工厂的接口和产品的接口，在Roles中有一个抽象工厂

9、方法Fire(),实例化子弹的任务被移动到这个方法中，此方法就如同是一个“工厂”。Roles并不决定要实例化的类，而是由子类（Hero，EnemyOne，EnemyTwo）来决定要实例化的类.抽象类Missiles的子类MissileHero,MissileOne,MissileTwo是由“工厂”（Hero，EnemyOne，EnemyTwo）来实例化的，比如Hero是负责实例化MissileHero的，EnemyOne是负责实例化MissileOne的，EnemyTwo是负责实例化MissileTwo的。这样就可以让把实例化推迟到子类。这个设计模式中运用到的设计原则有：依赖抽象，不要依赖具体

10、的类。B. 类 图C. 工厂模式的实现代码生产子弹的创建者类：public abstract class Roles /属性 public abstract void Fire();/用来生产子弹，实例化子弹的任务被移到一个方法中，此方法就如同是一个工厂方法 /其他的方法生产具体子弹的工厂:public class Hero : Roles /英雄类中的Fire()产生MissileHero public override void Fire() public class EnemyOne : Roles / EnemyOne类中的Fire()产生MissileOne public overr

11、ide void Fire() public class EnemyTwo : Roles / EnemyTwo类中的Fire()产生MissileTwopublic override void Fire() 子弹的抽象类：public abstract class Missiles protected override void Move() protected void Draw(Graphics g) 具体的子弹：/Hero的子弹public class MissileHero : Missiles / EnemyOne的子弹public class MissileOne : Missi

12、les / EnemyTwo的子弹public class MissileTwo : Missiles (三) 策略模式A. 设计说明上面讨论了每个角色都有自己的子弹，但是考虑到每个角色产生子弹的方式又是不一样的，我们可以设计不同的子弹产生方式，比如，Hero在某些时候可以一次产生一个子弹，但是当敌人比较多的时候，可以一次产生两个子弹，或者更多，敌人也是一样的，也可以一次产生多个子弹，达到增强战斗力的效果，这里就可以采用策略模式来设计每个角色产生子弹的行为。设计了一个接口ShotBehavior来封装发射子弹的行为，然后可以定义不同的行为，接着，在Roles类中加入一个实例变量shotBeha

13、viro，声明为接口类型，每个角色都会动态的设置这些变量以在运行时引用正确的行为类型，同一个角色可以采用不同的行为，实现不同的策略，并通过SetShotBehavior()来动态的改变发射子弹的行为。这样算法的变化就独立于使用算法的类了。这使得系统具有良好的扩展性和可维护性这个设计模式中运用到的设计原则有： 1.封装变化。 2.依赖抽象，不要依赖具体类。 3.针对接口编程，不针对实现编程 B. 类图C. 策略模式的实现代码public abstract class Roles protected ShotBehaviro shotBehavior;/行为变量被声明为行为”接口”类型 publi

14、c abstract void Fire();/动态设置不同的行为public void SetShotBehavior(ShotBehaviro newShotBehavior)shotBehavior= newShotBehavior;public class Hero : Rolespublic Hero()shotBehavior=new ShotThreeMissileHero(); public override void Fire() shotBehavior.Shot(); /这个接口用来封装发射子弹的行为public interface ShotBehavior public

15、 void Shot();public class ShotOneMissileHero:ShotBehavior /一次发射一个子弹 public void Shot() HitCheck.GetInstance().AddElement(new MissileHero(); public class ShotTwoMissileHero : ShotBehavior /一次发射两个子弹 public void Shot() HitCheck.GetInstance().AddElement(new MissileHero(); HitCheck.GetInstance().AddEleme

16、nt(new MissileHero(); public class ShotThreeMissileHero : ShotBehavior /一次发射三个子弹 public void Shot() HitCheck.GetInstance().AddElement(new MissileHero(); HitCheck.GetInstance().AddElement(new MissileHero(); HitCheck.GetInstance().AddElement(new MissileHero(); (四) 观察者模式A. 设计说明游戏中由于HitCheck控制所有角色，所以游戏中

17、的角色都要通过他来添加到游戏中，这样这些角色就成为了观察者了，然后由HitCheck去通知所有添加的观察者，这里就可以用到观察者模式，游戏中设计了一个所有类的父类Element,他有一个方法Draw(),所有的角色都实现了抽象类Element的Draw()方法，在游戏主程序中，当游戏状态改变时，都需要调用Draw()方法，以便更新自己最新的状态，所以，当游戏中的状态发生改变的时候，HitCheck类就会通知所有向他注册的观察者（调用观察者的Draw()方法），这样HitCheck不知道观察者的细节，只知道所有的观察者都实现了一个公共的接口（Draw），从而实现了观察者与可观察者之间的松耦合。这

18、个模式中用到的设计原则有:为交互对象之间的松耦合设计而努力B. 类图C. 观察者模式的实现代码public class HitCheck /记录观察者 private Hero myHero = null; private List missileHero = new List(); private List enemy = new List(); private List enemyMissile = new List(); private List bombs = new List(); /添加观察者 public void AddElement(Element el) if (el is

19、 Hero) myHero = (Hero)el; return; if (el is MissileHero) missileHero.Add(MissileHero)el); return; /剩下的几种角色类型的操作与上面的一样，这里就省略不写了 /删除观察者 public void RemoveElement(Element el) if (el is MissileHero) missileHero.Remove(MissileHero)el); return; if (el is Roles) enemy.Remove(Roles)el); return; /剩下的几种角色类型的操

20、作与上面的一样，这里就省略不写了 /通知观察者，让所有观察者调用Draw()方法画自己 public void Draw(Graphics g) /画自己(Hero) myHero.Draw(g); /画自己的子弹 for (int i = 0; i missileHero.Count; i+) missileHeroi.Draw(g); /剩下的几种角色类型的操作与上面的一样，这里就省略不写了 (五) 外观模式A. 设计说明由于游戏中使用了许多资源，在游戏结束的时候，要清理这些资源，最直接的方法就是针对每一种资源分别清理，即分别调用资源的Dispose()方法，在资源还不多的时候，可能还没有

21、什么影响，但是如果系统资源多了，这样效率明显就降低了，如果把这些组件整合成一个统一的接口，就可以解决问题了，这里我们就可以用到了外观模式了，FrmMain_FormClosing()提供了一个简单的接口，负责清理一切资源，其中，每项任务都是委托子系统中相应的组件处理的，现在我们在游戏结束的时候，只需要使用简化的接口FrmMain_FormClosing()就可以了，他提供了一个统一的接口，用来访问子系统中的一群接口，让子系统更容易使用。 这里运用到的设计原则有:最少知识原则，即只和你的密友谈话B. 类图C. 外观模式的实现代码public partial class FrmMain /以下是我

22、们用到的子系统组件 public static Bitmap backgroundImg； private Bitmap bufferImg = null; private Graphics gImg = null; Thread pt = null; /游戏结束，释放所有资源 private void Closing(object sender, FormClosingEventArgs e) bufferImg.Dispose(); gImg.Dispose(); backgroundImg.Dispose(); (六) 代理模式A. 设计说明游戏中，在设计BloodBar的时候，Bloo

23、dBar是不能单独存在的，BloodBar是需要绑定一个角色存在的，他是角色的生命值的体现，在游戏中，单独对BloodBar的访问是没有意义的，游戏中也不能直接对BloodBar进行访问，对BloodBar的访问受到了控制，只能通过相应的角色去访问BloodBar，这就可以用到代理模式，游戏中的Hero就是BloodBar的代理(代表)，他控制着外界对BloodBar的访问，当外界需要访问BloodBar时，被Hero拦截下来，由Hero去处理相应的请求，Hero对BloodBar提供了某些级别的保护，保证了外界不能直接去访问BloodBar，只有通过Hero才可以去访问Hero，通过Hero

24、去访问BloodBar这个过程对外界来说是透明的，外界觉得是直接访问BloodBar的，这样，Hero对BloodBar就起到了一种代理的作用，保护了BloodBar。B. 类图C. 代理模式的实现代码public abstract class Element public abstract void Draw(Graphics g);public class BloodBar : Element public override void Draw(System.Drawing.Graphics g) g.DrawString(); g.DrawRectangle(); g.FillRectangle(); public class Hero : Element/Hero中持有BloodBar的引用，负责对它的访问控制,使得外界不能直接对BloodBar进行访问public BloodBar bloodBar = null;public Hero() bloodBar= new BloodBar();/实例化BloodBar public override void Draw(System.Drawing.Graphics g) /在该方法中实现对bloodBar的访问控制 bloodBar.NowLife = life;/设置其生命值 bloodBar.Draw(g);