高级软件工程建设师详细设计.pptVIP

为什么这是优秀的设计？——解救篇 优秀设计第一法则——开闭原则 何谓开闭原则？软件组成实体（类、模块、函数，等等）应该是可扩展的，但是不可修改的。（即软件实体可以通过增加代码实现扩展，但是不能修改已有代码）。 如何实现开闭原则？——2个基本思想 共性和可变性分析 正确的接受现实——重构 为什么这是优秀的设计？——解救篇 共性可变性分析 实现抽象：在oopl中，可以创建出固定却能描述一组任意个可能行为的抽象体，这个抽象就像抽象基类或者接口，任意可能的行为就是可能的派生类。 针对接口（抽象）设计：由于模块之间依赖一个固定的抽象，所以它对更改可以是关闭的。 注意抽象有度 为什么这是优秀的设计？——重构篇 正确的接受现实——重构 面对复杂的领域多变性，设计师根据经验猜测程序可能遭遇的变化，如果猜测正确，获得成功；如果猜测错误，遭受失败。 有时为了不必要的复杂性，我们会被愚弄（没有抽象）。但是当变化发生时，我们就应该创建抽象进行隔离以后的同类变化。（题外话：我们设计人员应该积极地参与到需求过程，这样我们的预测才有可能正确！） 即对软件内部结构的一种调整，目的是不改变功能的前提下，提高其可理解性，降低其修改成本 代码的坏味道与重构 代码的坏味道概述 坏味道解决之道-重构技术 坏味道 代码坏味道(code smell),是指在代码之中潜在问题的警示信号.并非所有的坏味道 所指示的确实是问题,但是对于大多数坏味道,均很有必要加以查看,并做出相应决定 代码坏味道是需要重构的症状。或者潜在的问题（Potential Problem）或者缺陷（Flaw） 代码坏味道和拙劣设计相比是低的层次,重点在代码的层次 生病的症状 21种代码坏味道-1 Duplicated Code 重复代码　 Long Method 过长方法　 Large Class 过长类　 Long Parameter List 过长参数列表　 Divergent Change 发散式变化　 Shotgun Surgery 霰弹式修改　 Feature Envy 特性依恋　 Data Clumps 数据泥团　 Primitive Obsession 基本类型偏执　 Switch Statements switch语句　 21种代码坏味道-2 Data Class 数据类　 Refused Bequest 拒绝继承　 Comments 注释过多 Temporary Field 临时字段　 Message Chains 消息链　 Middle Man 中间人　 Inappropriate Intimacy 过度亲密　 Lazy Class 冗余类　　 21种代码坏味道-3 Parallel Inheritance Hierarchies平 行继承体系　 Speculative Generality 理论上的一般性　 Alternative Classes with Different Interfaces接 口不同的等效类 Incomplete Library Class 不完整的库类 21种代码坏味道_治疗手段 软件重构—面临的困难 程序员方面 公司方面 如何改变现状 程序员方面 不知道如何去重构，认识没有达到一定程度。 程序员的认识有问题，认为别人写的垃圾都 很垃圾不如自己写的，还不如将此功能块重新开发。 个人误区，认为做新项目好，能学到新的东西，不喜欢维护旧项目，忽略了提高技能，而不是技巧。 公司方面 认为做出来东西才有价值，因为你做了两个月，可能界面和功 能一点都没有变。 公司没有那么多时间和精力让你去重构 对项目的工期评估有问题： 根据业界统计： 其中一个项目从设计到上线运行，前期的总成本和工时只占 软件总成本和总工时的20%-40%，后期占60%-80%。 重构过程中，没有为公司带来直接的价格，不如新开发项目。 如何改变现状 尽量挤时间从设计开始就不断去重构，开发中更要重视重构， 不要等到项目都要上线了，再去想着重构 积极去面对重构 下面看一个实际项目中重构的例子 回顾 架构的输出=详细设计的输入 （结构视图） 一个菜鸟的代码成长过程 什么是优秀的设计？ 做设计的一些基本法则？ 为什么要重构？如何重构？ 重构遇到的问题，如何去解决？ 谢谢！！！ * * ? Evolve by case 我们来看设计 前言 架构的输出=详细设计的输入 （结构视图） 一个菜鸟的代码成长过程 什么是优秀的设计？ 做设计的一些基本法则？ 为什么要重构？如何重构？ 重构遇到的问题，如何去解决 我们所处的位置——需求/架构/设计关系 架构的输出=详细设计的输入 功能视图