火龙果代码重构.pptVIP

由于存在着一些特殊的情况，以及需要设置终止递归的条件。因此实际的处理过程要更为复杂些最简单的情况就是，当正则表达式推进到末尾时(regexp[0] == \0)，所有前面的判断都成功了，那么这个正则表达式就与文本匹配。 如果正则表达式是一个字符后面跟着一个*，那么将会调用matchstar来判断闭包（closure）是否匹配。函数matchstar(c, regexp, text)将尝试匹配重复的文本字符c，从零重复开始并且不断累加，直到匹配text的剩余字符，如果匹配失败，那么函数就认为不存在匹配。这个算法将识别出一个“最短的匹配”，这对简单的模式匹配来说是很好的。 如果没有包含$，并且如果当前不是处于text字符串的末尾（也就是说，*text!=\0）并且如果text字符串的第一个字符匹配正则表达式的第一个字符，那么到现在为止都是没有问题的；我们将接着判断正则表达式的下一个字符是否匹配text的下一个字符，这是通过递归调用matchhere函数来实现的。这个递归调用不仅是本算法的核心，也是这段代码如此紧凑和整洁的原因。 如果所有这些匹配尝试都失败了，那么正则表达式和text在这个位置上就不存在匹配，因此函数matchhere将返回0。 在这段代码中大量地使用了C指针。在递归的每个阶段，如果存在某个字符匹配，那么在随后的递归调用中将执行指针算法（例如，regexp+1 and text+1），这样在随后的函数调用中，参数就是正则表达式的下一个字符和text的下一个字符。递归的深度不会超过匹配模式的长度，而通常情况下匹配模式的长度都是很短的，因此不会出现耗尽内存空间的危险。 现在，Customer class 内的任何代码都可以取用这些query methods 了。如果系统他处需要这些信息，也可以轻松地将query methods 加入Customer class 接口。如果没有这些query methods，其他函数就必须了解Rental class，并自行建立循环。在一个复杂系统中，这将使程序的编写难度和维护难度大大增加。可以很明显看出来，htmlStatement()和statement()是不同的。现在，应该脱下”重构“的帽子，戴上“添加功能“的帽子。 运用多态取代与价格相关的条件逻辑 这个问题的第一部分是switch 语句。在另一个对象的属性（attribute）基础上运用switch 语句，并不是什么好主意。如果不得不使用，也应该在对象自己的数据上使用，而不是在别的类的数据上使用。这暗示getCharge()应该移到Movie class中去。 为了达到上述目的，必须把“租期长度” 作为参数传递进去。 “租期长度”来自Rental对象。计算费用时需要两个数据： “租期长度”和“影片类型” 。为 什么选择“将租期长度传给Movie对象”而不是“将影片类型传给Rental 对象”呢？因为本系统可能发生的变化是加入新影片类型，这种变化带有不稳定倾向。如果影片类型有所变化，希望掀起最小的连漪，所以选择在Movie 对象内计算费用。 Class Movie Class Rental Class Rental Class Rental Class Movie 有数种影片类型，它们以不同的方式回答相同的问题。这听起来很像subclasses的工作。可以建立Movie的三个是subclasses，每个都有自己的计费法 这样可以运用多态来取代switch 语句了。但是这里有个小问题：一部影片可以在生命週期内修改自己的分类，一个对象却不能在生命周期内修改自己所属的class。采用Strategy Pattern（模式）。运用它之后，classes 的结构如下。 意味必须在Movie class 内保存一个Price 对象，而不再是保存一个_priceCode变量，还需要修改访问函数。 要对getCharge()实施Move Method Class Movie 运用Replace Conditional with Polymorphism，做法是一次取出一个case分支，在相应的class内重载该函数 处理完所有case分支之后，把Price.getCharge()声明为abstract 运用同样方法处理getFrequentRenterPoints()函数 引入Strategy模式值得吗？这么做的收获是：如果要修改任何与价格有关的行为，或是添加新的定价标准，或是加入其他取决于价格的行为，程序的修改会容易得多。这个程序的其余部分并不知道运用了Strategy模式。对于目前拥有的这么几个小量行为来说，任何功能或特性上的修改也许不困难，但如果在一个更复杂的系统中，有十多个与价格相关的函数，程序的修改难易度就会有很大的区别。以上所