标签：style blog http color 使用 ar 2014 sp 代码
上图和代码显示 应用程序中有3个模块，或者子程序。copy模块调用另外两个模块。copy从read keyboard中获取字符，并把字符传递给write printer模块。
。。。。需求在变化：
希望copy可以从纸带读入机中读入信息：如果变量值为false，就像以前一样从键盘读取信息。槽糕的是，现在已有许多其他程序正在使用copy程序，你不能改变copy程序的接口。改变接口会导致长时间的重新编译和重新测试。
打补丁：
当然会想到使用一个全局变量的方法，结果如下：
想让copy从纸带读入信息设置ptFlag为true即可，然后再调用copy，它就会正确地从纸带读入信息，一旦copy调用返回，调用者必须要重新设置ptFlag。
。。。。
需要再次改变：
客户希望copy程序可以输出到纸带穿空机上。
如果继续这样的打补丁，软件终会变的难以维护。
这次的设计的改动和上次的相似。只不过需要另外一个全局变量和？操作符。
—————————————————————————————————————————————————————————————————————————————
说上面的例子不是要吐槽客户的需要改变，实际中，客户的需要一定是会有变化的。
通过上面的例子可以看到在 变化面前程序的设计退化的速度是多么的快。copy程序的原始设计是简单的，是优雅的。但是仅仅经历了两次变更，它就已经表现出了僵化性、脆弱性和不必要的复杂性、不必要的重复急晦涩性的症状。
记住，在大多数软件项目中最不稳定的就是需求。需要处在一个持续变动的状态之中。这是我们作为开发人员必须得接受的事实！
一个好的解决方案：
在这个例子中，在我们遇到第一个需求变化时，我们要修改设计并使修改后的设计对于那一类的需求的变化具有弹性。
在要实现新需求时，团队抓住这次机会去改变设计，以便设计对于将来的同类变化具有弹性，而不是设法去给设计打补丁。
标签：style blog http color 使用 ar 2014 sp 代码
原文地址：http://blog.csdn.net/u011409995/article/details/39184949
