敏捷软件开发第四讲-敏捷设计SRP(单一职责原则)课件解说.pptVIP

一个程序设计的腐化过程 老板给你的任务。。。。。。 　　老板一大早就来找你，要你务必在三个星期内完成这样一个程序：从键盘读入字符，并输出到打印机。 　　你是一个很有效率的开发人员，仅仅用了两个星期就把程序完成了（Copy V1）： void Copy() { int c; While ((c = RdKbd()) !=EOF) WrtPrt(c); } 一个程序设计的腐化过程 需求在变化。。。。。。 　 　三个月后的某天的某个上午，老板又来找你，说有时希望能从纸带读入机读入信息。你咬牙切齿，翻着白眼。你想知道为何人们总是改变需求。你的程序不是为纸 带读入机设计的！你警告老板，这样的改变会破坏程序的优雅。不过老板怒视了你一下，你又立刻低下了头，开始想解决方案了。 　　 一个程序设计的腐化过程 因为程序已经 安装到数百个工作站，你不能改变Copy程序的接口。改变接口会导致长时间的重新编译和重新测试。单单系统测试工程师就会痛恨你，更别提配置控制组的那7 个家伙了。并且过程控制部门会用专门的一天时间来对所有调用了Copy的模块进行各种各样的代码评审。但是这也难不到你，你巧妙地完成了任务（Copy V2）： bool ptFlag = false; void void Copy() { int c; While ((c = (ptFlag ? Rdpt() : RdKbd())) !=EOF) WrtPrt(c); } 一个程序设计的腐化过程 得寸进尺。。。。。。 美好的日子过得总是太快，几个礼拜后的那天早上老板又来光顾你，他说：客户有时希望Copy程序可以输出到纸带穿孔机上。客户！他们总是毁坏你的设计。如果没有客户，编写软件会变得容易得多。 你再次警告老板，如果继续以这样可怕的速度变更需求，那么在年底前软件就会变得难以维护了。老板心照不宣地点点头，接着告诉你无论如何都要进行这次改动。 这次的改动和上次相似，只不过需要另外一个全局变量，下面的程序展示了你努力后的卓越成果（Copy V3）： 一个程序设计的腐化过程 得寸进尺。。。。。。 美好的日子过得总是太快，几个礼拜后的那天早上老板又来光顾你，他说：客户有时希望Copy程序可以输出到纸带穿孔机上。客户！他们总是毁坏你的设计。如果没有客户，编写软件会变得容易得多。 你再次警告老板，如果继续以这样可怕的速度变更需求，那么在年底前软件就会变得难以维护了。老板心照不宣地点点头，接着告诉你无论如何都要进行这次改动。 一个程序设计的腐化过程 bool ptFlag = false; bool punchFlag = false; void Copy() { int c; While ((c = (ptFlag ? Rdpt() : RdKbd())) != EOF)) punchFlag ? WrtPunch(c) : WrtPrc(c); } 这次的改动和上次相似，只不过需要另外一个全局变量，下面的程序展示了你努力后的卓越成果（Copy V3）： 一个程序设计的腐化过程 崩溃。。。。。。 很不幸，没过两个星期。那天早上你刚到办公室还没坐下，老板又跑了进来，看他焦急的神态你猜得出他已经等了你3个小时了。老板开门见山地说：客户有时希望Copy程序可以从文件中输入… 什么激发了软件的腐化？ 答案是需求的变化。由于需求没有按照初始设计预见的方式进行变化，从而导致了设计的退化。通常，改动都很急迫，并且进行改动的开发人员对原始的设计思路并不熟识。因而，虽然对设计的改动可以工作，但是它却以某种方式违反了原始的设计。随着改动的不断进行，这些违反不断地积累，设计开始出现臭味。 什么激发了软件的腐化？ 然而，我们不能因为设计的退化而责怪需求的变化。作为开发人员，我们对需求变化有非常好的了解。 事实上，我们中的大多数人都认识到需求是项目中最不稳定的因 素。如果我们的设计由于持续、大量的需求变化而失败，那就表明我们的设计和实践本身是有缺陷的。我们必须要设法找到一种方法，使得设计对于变化具有弹性， 并且应用一些实践来防止设计腐化。 设计原则概述 软件的可维护性和可复用性 软件工程和建模大师Peter Coad认为，一个好的系统设计应该具备如下三个性质： 可扩展性(Extensibility) 灵活性(Flexibility) 可插入性(Pluggability) 运用面向对象设计原则设计Copy程序