面向对象软件开发的敏捷过程Word下载.docx

资源描述

面向对象软件开发的敏捷过程Word下载.docx

《面向对象软件开发的敏捷过程Word下载.docx》由会员分享，可在线阅读，更多相关《面向对象软件开发的敏捷过程Word下载.docx（10页珍藏版）》请在冰豆网上搜索。

面向对象软件开发的敏捷过程Word下载.docx

fragility对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

出现新问题的地方和改动的地方没有概念上的关联，难以排错，排错的过程中又会引入更多的&

臭虫&

。

牢固性immobility很难解开系统的纠结，使它成为其他系统中重用的组件。

系统中包含了对其他系统中有用的功能，当其他人想复用这个功能到新的系统时，剥离出独立的组件的难度远远大于重新实现的难度，在时间和进度的压力下，大多数人只有选择拷贝涂鸦的方式来实现新系统的功能。

粘滞性：

viscosity做正确的事情比错误的事情要困难。

程序完成正常的功能总是倾向于得到不正确的结果。

不必要的复杂性：

needlesscomplexity设计中包含有不具有任何直接好处的基础结构。

为了预防后期维护更改需求的对源码的修改，在设计之初放置了那些处理潜在变化的代码来保持软件的灵活性，这样的结果是软件中包含了很多复杂的结构，理解起来更加困难。

不必要的重复：

needlessrepetition设计中包含有重复的结构，而该重复的结构可以使用单一的抽象进行统一。

对鼠标右键（剪切，复制，粘贴）的滥用，使得完成同一或类似的代码片断出现在系统各处。

如果原始的代码段完成的功能需要变化，或者存在错误，排错和增加新的功能变得非常困难。

晦涩性：

opacity很难阅读，理解。

没有很好的表现出意图。

以上讨论了系统构架的臭味，下面讨论微观层次上代码的臭味：

代码的臭味

重复代码：

重复的代码使得更改功能和排错更加困难。

同样的模块错误会在拷贝粘贴的程序各处多次出现。

过长的函数：

程序越长越难于理解，这已经是软件业开发的常识。

越难理解的程序，使用维护的成本就越大。

如果一个函数的行数超过一页，很少有人能够在看到下一页的时候还清楚的记得函数开头的变量定义，理解和查错更加困难。

过大类：

在一个类中完成几乎所有需要的功能。

十项全能的人是不存在的，软件也一样。

过长的参数列：

如果一个函数（方法）的调用参数过长，使用这个函数的调用过程也一定是困难的。

想象一下，调用一个十个以上参数存储过程会有多么痛苦。

这还只是开始，如果任一个参数的定义（名称，类型）发生轻微的变化，函数的调用客户端会有多么大的改动。

其他的臭味还有发散式变化，散弹枪修改，依恋情结，数据泥团，基本型别偏执，复杂的switch分支语句，平行的继承体系，冗赘类，夸夸其谈的未来性，令人迷惑的暂时值域，过度耦合的消息链，中间转手人，狎昵关系，异曲同工的类，不完美的程序库类，纯数据类（数据哑元），子类不需要父类的某些特性，过多注释。

详细的讨论可以参见《重构》的介绍。

面向对象软件设计的原则：

总体原则：

1．针对于接口（抽象）编程，而不要针对于实现（具体）编程。

举例来说：

操作系统是对逻辑计算机的抽象，通过操作系统的抽象我们不需要考虑具体使用的硬件配置，可以在较高的层次上进行更高生产力的应用。

再如：

汇编语言对机器的0，1代码进行了抽象，大大加快了开发效率，后来使用的高级语言和第四代语言模型驱动抽象的级别更高，生产力也更高。

java和.net实现于一个抽象的软件虚拟机，进一步使开发出来的组件可以跨平台和操作系统。

通过抽象出数据访问层（持久化层），可以使业务逻辑和具体的数据库访问代码分离，更换数据库提供商对已有的组件没有影响。

具体实现可以参照hibernate实现和dao（数据访问对象）模式。

优势：

1）降低程序各个部分之间的耦合性，使程序模块互换成为可能。

调用的客户端无需知道具体使用的对象类型，只要对象有客户希望的接口就可以使用，对象具体是如何实现这些接口的，客户并不需要考虑。

2）简化了程序各个部分的单元测试，将需要测试的程序模块中通过重构提炼出抽象的接口，然后编制和接口一致的Mock类，测试就会变得很容易。

如果应用了测试优先的方法，从简化客户端调用的角度，还可以经过抽象改善软件模块的设计。

3）模块的部署升级由于模块之间的耦合度降低变得更加容易。

相关的设计模式有创建型模式中的工厂模式，结构型模式中的代理模式和组合模式等。

2．对象组合优于类继承。

面向对象为软件开发引入了三大工具：

继承，多态和重载。

继承使得程序员可以快速的通过扩展子类来增加功能，但是由于继承是在编译时确定的，因此增加的功能较多时，继承不够灵活，还有可能出现&

子类爆炸&

的局面（为了完成新添功能，不得不在继承体系中添入大量的之间只有细微差别的子类，掌握使用扩展都会变得非常困难）。

而通过对象的组合，可以动态透明的添加功能。

相关设计模式有装饰模式和代理模式等。

3．分离变化。

前面说过需求是在不断变化的，不同的变化可能是仓库安全库存的计算方法，可能是报表和数据的展现形式，通过把这些不同的变化识别并分离出来不同的对象委托，简化了客户端的调用和升级。

相关的设计模式有命令模式，观察者模式，策略模式，状态模式，模版方法模式等。

具体原则：

1．单一职责原则srp（singleresponsibilityprinciple）：

一个模块的功能应该尽可能的内聚。

如果一个类发生了变化，引起变化的原因应该有且只有一个。

每一个类承担的职责都是一个变化的轴线，需求变化时，会体现为类的职责的变化。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化会影响这个类完成其他职责的能力，会出现前面所说的软件的臭味之一脆弱性。