高级软件工程之创新设计模式.ppt

模式与反模式的关系 模式和反模式是相互关联的。设计模式常常有可能转化成反模式。一个流行的模式，可能在某个时期是受欢迎的的范例，慢慢地大家更清楚地了解到它所导致的后果而不再受宠。模式解决方案与反模式解决方案之间的区别在于它们的上下文环境；处于不合适的上下文环境中的模式就变成了反模式。当一个模式变成反模式时，具备将该解决方案转换成更好方案的能力是大有裨益的。 开发性反模式 The Blob 胖球：过程式风格的设计导致一个对象承担大量职责，而大部分其他对象则只用于保存数据或执行简单的处理。 Lava Flow 岩浆流：代码中存在历史原因造成的没有功能、无法理解的代码。 Functional Decomposition 功能分解： 非面向对象开发人员使用面向对象语言来设计实现一个应用时常出现. Poltergeist 恶作剧鬼：指那些职责和有效生命周期都很有限的类，用于启动其他更为持久的类中的某些操作。 Golden Hammer 金锤：是指把一种熟悉的技术或概念强迫性的应用于许多软件问题。 Spaghetti Code 面条代码：即兴生成的软件结构导致难以扩展和优化代码。 Cut-And-Paste Programming 剪贴编程：通过剪贴语句形成的代码复用会导致显著的维护问题。 管理性反模式 Analysis Paralysis 分析瘫痪：分析阶段追求完美和完备。重构：增量式开发：内部（基础结构）外部（功能）。 Death By Planning 规划致死：过规划。在规划、制定进度表和捕获进度方面缺乏注重时效的方法。重构：项目计划应该显示出主要的交付品。完成度应该是总体粗略的度量而不是精细的度量。 Corncob 玉米棒子：难以相处的人。重构：战术（转移责任给反对者，隔离问题（采用大多数人意见），质疑问题（要求Corncob澄清观点，证明论据））、战役（离线地。矫正性会谈，介绍新职）、战略（Croncob支持组，把corncob放到一组，空部门，开除）。 Irrational Management 非理性管理：管理者的决策不是深思熟虑的战略，而是膝跳反应。项目拷问，对某个话题进行争论。重构：1）承认问题，寻求帮助。2）理解开发部署（了解部署的技术能力和个性特点）3）提供清晰的短期目标。4）团队拥有共同目标。5）对过程进行改进。6）推动交流。7）管理交流机制。8）异常管理。9）采用有效的决策制度方法：情况分析，决策分析。 Project Mismanagement 项目管理不善：关键活动被忽视或减少：不充分的架构、代码审查不足，测试覆盖不充分。重构：限制风险：管理风险、常见项目失败点、质量风险；建立共同理解。在架构层次定义模块依赖。在设计层次，定义跨越模块的控制用例。 架构性反模式 Stovepipe Enterprise 烟囱企业：企业的多个系统独立设计、缺乏共同性，阻碍了复用。“自动化孤岛”。重构：在多个层次上协调，定义参考模型。 Stovepipe System 烟囱系统：单系统中缺乏通用的子系统抽象，子系统被使用多种集成策略和机制随意组合在一起。重构：定义一个共同的服务接口（构建架构）。 Vendor Lock-In 供应商锁定：重构：隔离层。 Architecture By Implication 实现主导架构：系统缺乏架构规范：语言和库的使用，编码标准，内存管理等。重构：有组织的方式进行系统定义。多个视图。4+1 Model View，逻辑视图，用例视图，过程视图，实现视图，开发视图。 Design By Commitee 委员会设计：太多人参加设计导致概念不清。重构：改革会议过程，1）提出问题 2）安静地写下答复 3）扔纸团 4）随机读出答复 5）达成共识 6）去除重复 7）确定优先级 8）讨论。反例：SQL、CORBA Reinvent the Wheel 重新发明轮子：从头开始建立定制的软件。绿地系统假设。重构：从先前存在的架构中提取有价值的信息，架构挖掘：1）对各种代表性技术进行建模，以便产生相关软件接口的规范。2）对设计进行贵拉来建立通用接口规范。3）对设计进行精炼。 GoF设计模式交流方案 GoF设计模式交流方案 GoF设计模式交流方案 GoF设计模式交流方案 GoF设计模式交流方案 GoF设计模式交流方案 GoF设计模式交流方案 GoF设计模式交流方案 第一轮（1-23）每人讲解10-15分钟，主要讲解每种模式的动机、定义、结构、角色和应用举例； 第二轮（24-46）每人讲解8-10分钟，主要讲解每种模式的优缺点和应用举例，包括例子代码的介绍和程序运行结果展示； 第三轮（47-81）每人讲解6-8分钟，重点讲解每种模式的应用例子，包括例子代码的介绍和程序运行结果展示。要求和第一、二轮同学举的例子不同；