第5章设计模式分析.pptVIP

5.3 常用设计模式 ●策略模式 策略模式定义了算法族（比较规则），分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 （摘录自：《HeadFirst设计模式》） 5.3 常用设计模式 ●状态模式 问题提出：MP3播放器，能在播放、暂停、停止之间切换。详细要求： -播放状态下可响应暂停、停止操作 -暂停状态下课响应播放、停止操作 -停止状态下只能响应播放操作 补充说明，提供以下函数： void Play() : 停止到播放时调用 void Pause() ： 播放到暂停时调用 void Resume()：暂停到播放时调用 void Stop()：播放或暂停 到 停止时调用 键盘上输入1，代表按下播放键；键盘上输入2，代表按下暂停键；键盘上输入3，代表按下停止键。 5.3 常用设计模式 问题分析：这是一个非常典型的有限状态机（Finite State Machine, FSM），通过状态图来描述一下问题： Stop Play Pause PlayKey / Play() StopKey / Stop() PauseKey / Pause() PauseKey or PlayKey / Resume() StopKey / Stop() 5.3 常用设计模式 常见做法：通过嵌套switch-case来实现 5.3 常用设计模式 优点 -代码逻辑简单，易理解 -对于简单的状态机，可采用嵌套switch-case结构 缺点 -对于有多个状态、多个事件的状态机，代码冗长，解读和维护将变得异常困难。 -状态机逻辑和实现动作的代码没有很好地分离。 5.3 常用设计模式 解决方案：通过查表代替嵌套switch-case结构： typedef enum tagState_t { STS_PLAY, STS_PAUSE, STS_STOP, STS_MAX }State_t; typedef struct tagPlayMgr_t{ State_t NextSts; void (*Action)(void); }PlayMgr_t; PlayMgr_t MyMgrTbl[]={{STS_PLAY,play},{STS_PAUSE,pause},{STS_STOP,stop},{STS_MAX,NULL}}; 谢谢！ * 设计模式要遵循设计原则，设计原则本身也是成熟的设计模式。 设计模式像极了咱们老祖宗传下来的中国功夫，可能就是简单的二十四式，只要招式烂熟与胸，实战时，一切都会自然流露，不会特意去想用哪一招。而是完全根据场景，对手、目标而自然的出招。如果说你的代码中没有用到模式，那可能实战就是泼妇打架，一通乱拳了，高手当然不会如此。学习模式的一个捷径是看一些经典成熟的代码。 设计模式要遵循设计原则，设计原则本身也是成熟的设计模式。 * 这是通常做法 * 分析：每个函数的处理流程相同，只是处理的数据和执行的动作不同罢了。 能否将处理流程独立出来，让处理的数据和执行的动作以参数的形式传递给函数呢？ * * 不好的做法 * Entities：实体;实际存在物;本质 解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。 * Parser:分析器 * * 输入命令时，同时确定argv[i] * * * * * * 第五章 设计模式 目标: 本章旨在向学员介绍： 5.1 什么是设计模式 5.2 常用设计原则 5.3 常用设计模式 时间：4学时 教学方法：讲授PPT+ 案例分析 软件之美在于它的功能，在于它的内部结构，还在于团队创建它的过程。对用户来说，通过直观、简单的界面呈现出恰当特性的程序就是美的。对软件设计者来说，被简单、直观地分割，并具有最小内部耦合的内部结构就是美的。对开发人员和管理者来说，每周都会取得重大进展，并且生产出无缺陷代码的具有活力的团队就是美的。美存在于所有这些层次之中 。 最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。软件开发新手往往不理解这点。他们认为做每件事情都必须要快，他们认为美是不实用的。错！由于事情做得过快，他们造成的混乱致使软件僵化，难以理解。美的系统是灵活、易于理解的，构建、维护它们就是一种快乐。丑陋的系统才是不实用的。丑陋会降低你的开发速度，使你的软件昂贵而又脆弱。构建、维护美的系统所花费的代价最少，交付起来也最快。