代码重构优秀课件.pptVIP

代码重构 录像带租赁系统 操作员告诉程序：顾客租了哪些影片、租期多长，程序便根据租赁时间和影片类型算出费用。影片分为3类：普通片、儿童片和新片。除了计算费用，还要为常客计算积分；积分会随着租片种类是否为新片而有不同。 Customer 类中statement()做的事情实在太多了，它做了很多原本应该由其他class 完成的事情。 用户希望对系统做一点修改，希望以HTML 格式打印报表，这样就可以直接在网页上显示，这非常符合潮流。这个变化会带来什么影响，分析代码就会发现，根本不可能在打印HTML 报表的函数中复用（reuse）目前statement()的任何行为。惟一可以做的就是编写一个全新的htmlStatement()，大量重复statement()的行为。 如果计费标准发生变化，必须同时修改statement()和htmlStatement()，并确保两处修改的一致性。 用户希望改变影片分类规则，但是还没有决定怎么改。为了应付分类规则和计费规则的变化，程序必须对statement()作出修改。把statement()内的代码拷贝到用以打印HTML 报表的函数中，就必须确保将来的任何修改在两个地方保持一致。 随着各种规则变得愈来愈复杂，适当的修改点愈来愈难找，不犯错的机会也愈来愈少。 分解并重组statement() 本例一个明显的逻辑结构就是switch 语句，把它提炼（extract）到独立函数中似乎比较好。 首先在这段代码里面头找出函数内的局部变量和参数：each 和thisAmount，前者并未被修改，后者会被修改。任何不会被修改的变量都可以被当成参数传入新的函数，至于会被修改的变量就需格外小心。如果只有一个变量会被修改，可以把它当作返回值。thisAmount 是个临时变量，其值在每次循环起始处被设为0，并且在switch 语句之前不会改变，所以可以直接把新函数的返回值赋予它。 每次做完这样的修改之后，都要编译并测试。发现错误的将amountFor() 的返回值型别声明为int，而不是double。 搬移“金额计算” 代码 观察amountFor()时，发现这个函数使用了来自Rental class 的信息，却没有使用来自Customer class的信息。 怀疑它是否被放错了位置。绝大多数情况下，函数应该放在它所使用的数据的所属object（或说class）内，所以amountFor()应该移到Rental class去 。 去掉参数，此外还要在搬移的同时变更函数名称 搬移金额计算函数后，类的状态 thisAmount如今变成多余了。它接受each.getCharge()的执行结果，然后就不再有任何改变把thisAmount除去 除去类临时变量。临时变量往往形成问题，它们会导致大量参数被传来传去，而其实完全没有这种必要。你很容易失去它们的踪跡，尤其在长长的函数之中更是如此。当然我这麼做也需付出性能上的代价，例如本例的费用就被计算了两次。但是这很容易在Rental class中被优化。而且如果代码有合理的组织和管理，优化会有很好的效果。 这里有两个临时变量，两者都是用来从Customer对象相关的Rental对象中获得某个总量。不论ASCII版或HTML版都需要这些总量。运用Replace Temp with Query来取代totalAmount和frequentRentalPoints这两个临时变量。 做完这次重构，有必要停下来思考一下。大多数重构都会减少代码总量，但这次却增加了代码总量，那是因为Java 1.1 需要大量语句statements）来设置一个总和（summing）循环。哪怕只是一个简单的总和循环，每个元素只需一行代码，支持代码也需要六行之多。这其实是任何程序员都熟悉的习惯写法，但代码数量还是太多了。 这次重构存在另一个问题，那就是性能。原本代码只执行while 循环一次，新版本要执行3次。如果while 循环耗时很多，就可能大大降低程序的性能。单单为了这个原因，许多程序员就不愿进行这个重构动作。但是请注意：如果和可能。除非进行评测（profile），否则无法确定循环的执行时间，也无法知道这个循环是否被经常使用以至于影响系统的整体性能。重构时不必担心这些，优化时才需要担心它们，但那时候已处于一个比较有利的位置，有更多选择可以完成有效优化。 现在，Customer class 内的任何代码都可以取用这些query methods 了。如果系统他处需要这些信息，也可以轻松地将query methods 加入Customer class 接口。如果没有这些query methods，其他函数就必须了解Rental class，并自行建立循环。在一个复杂系统中，这将使程序的编写难度和维护难