『重构--改善既有代码的设计』读书笔记----Replace Temp with Query

Replace Temp with Query,顾名思义,表示你用查询来替换临时变量本身,临时变量对于函数来说是只有当前函数可见的,如果你在同类的别的地方要用到这个变量你就必须重新写表达式来获取这个变量,这样的话你就会在不经意间让你的函数变得复杂起来,所以如果你想要使用Extract Method,那么Replace Temp with Query是必不可少的一个步骤。而我们前面介绍的Inline Temp其实是这个手法的一部分,两者的区别在于Inline Temp已经有了表达式自身,只需要做简单的替换就可以,表示用表达式本身把临时变量给去掉。而Replace Temp with Query更加全面,里面包含了提炼表达式到函数本身,然后替换引用点(Inline Temp)。如果你把所有的临时变量都替换为一个查询,你的类的结构和逻辑将非常清晰,这样将更加有利于你的重构和进行优化。

这个重构手法有个很重要的前提就是临时变量只能被赋值一次,或者赋值给临时变量的表达式不受别的条件约束进行改变。对于其他情况,可能你应该需要Split Temporary Variable或Separate Query from Modifer把情况弄的简单点之后再运用本手法。对于有那种收集结果的临时变量或者循环中要进行累积的变量,你需要将程序的逻辑复制到查询函数中去。

做法一般都是找到只被赋值一次的临时变量,然后用const加以修饰进行编译(表示之后没有对这个变量进行修改),然后将所有对这个变量等号右边的表达式提炼到一个函数中去(这个步骤其实已经是Inline Temp的前提条件),然后将这个函数先声明为private(如果以后有别的类需要再改为public,这样可以保证接口的整洁性),判断这个查询函数本身会不会修改对象内容,如果会的话就需要运用Separate Query from Modifer进行重构。这些步骤都做好之后,就可以用Inline Temp将之前做好的函数进行变量替换。

有些同学可能会担心性能问题,我明明一个变量放在那好好的,你不要用,导致你每次去使用多要做一次查询。对于这种情况大可放心,重构的目的是让程序更加清晰,有了更加清晰的程序之后再具体做优化也不迟,况且根据二八原则,仅仅这条查询语句倘若你系统真的出现了性能问题也不大可能,如果实在是因为这条语句,你也可以把变量再放回去。

下面来看下具体例子:

double getPrice()
{
    int basePrice = m_quanity * m_itemPrice;
    double discountFactor;
    if (basePrice > 1000)
    {
        discountFactor = 0.95
    }
    else
    {
        discountFactor = 0.98
    }
    return basePrice * discountFactor;
}

例子很简单,但是有两个临时变量,可以看到basePrice和discountFactor都被赋值了一次,如果我想重构这个函数,我们上面讲到了,Extract Method之前要做Replace Temp with Query,那么用Query来取代这两个临时变量那会让我们更加清晰重构的路线。

首先第一步,我们来进行basePrice的提炼,在之前加上const,进行编译,发现没有问题。

double getPrice()
{
    const int basePrice = m_quanity * m_itemPrice;
    double discountFactor;
    if (basePrice > 1000)
    {
        discountFactor = 0.95
    }
    else
    {
        discountFactor = 0.98
    }
    return basePrice * discountFactor;
}

然后我们将等号之后的提炼到独立小函数中去(为了确保查询函数本身的特质--不修改对象本身,我们这里可以利用C++特性给函数加上const限定)

int basePrice() const
{
    return m_quanity * m_itemPrice;
}

这样原来的函数就变成了

double getPrice()
{
    const int basePrice = basePrice();
    double discountFactor;
    if (basePrice > 1000)
    {
        discountFactor = 0.95
    }
    else
    {
        discountFactor = 0.98
    }
    return basePrice * discountFactor;
}

然后逐步使用Inline Temp把对basePrice的地方进行替换并进行编译测试,最后直接把basePrice的声明去掉。重复这个动作来进行提炼discountFactor得到

double getPrice() const
{
    return basePrice() * discountFactor();
}

int basePrice() const
{
    return m_quanity * m_itemPrice;
}
double discountFactor(){    if (basePrice() > 1000)    {        return 0.95    }    else    {        return 0.98    }}

可以看到,在提炼discountFactor的时候,对于临时变量basePrice如果没有进行提炼,那么就需要将这个临时变量传进去。像这样

double discountFactor(int basePrice)
{
    if (basePrice > 1000)
    {
        return 0.95
    }
    else
    {
        return 0.98
    }
}

可以明显的看到,这个重构手法对于函数本身来说,提高了清晰度,也让我们进行后期重构能够更加便捷。

时间: 2024-11-09 04:28:22

『重构--改善既有代码的设计』读书笔记----Replace Temp with Query的相关文章

『重构--改善既有代码的设计』读书笔记----Replace Method with Method Object

有时候,当你遇到一个大型函数,里面的临时变量和参数多的让你觉得根本无法进行Extract Method.重构中也大力的推荐短小函数的好处,它所带来的解释性,复用性让你收益无穷.但如果你遇到上种情况,你可能会天真的以为我只要适当的进行Replace Temp with Query,就可以把这种现象给化解.但情况往往事与愿违,不能达到你所理想的高度.这个时候你需要用到重构中的杀手锏--Replace Method with Method Object,这个手法出自Kent Beck [Beck].

『重构--改善既有代码的设计』读书笔记----Replace Data Value with Object

当你在一个类中使用字段的时候,发现这个字段必须要和其他数据或者行为一起使用才有意义.你就应该考虑把这个数据项改成对象.在开发初期,我们对于新类中的字段往往会采取简单的基本类型形式来保存,但随着我们开发进度的增加,这些简单的数据项就不再那么简单了.比如一开始你会使用一个字符串来表示一串电话号码,但是随后你会发现,这个电话号码已经变的不再纯粹,它可能还需要“格式化”,“抽取取号”等特殊行为.一开始你可能会不以为意,觉得这个数据项就这么一两个,不会对你造成影响.但重复代码(Duplicate Code

『重构--改善既有代码的设计』读书笔记----Replace Array with Object

如果你有一个数组,其中的元素各自代表不同东西,比如你有一个 QList<QString> strList; 其中strList[0]代表选手姓名,strList[1]代表选手家庭住址,很显然这个数组表示的含义已经太多,你需要用对象来替换数组,并且对于数组中的每个元素,以一个字段来表示. 数组是一种常见的用以组织数据的数据结构,不过,它们应该只用于“以某种顺序容纳一组相似对象”.对于上面的例子你可以看到一个数组容纳了不同对象,这会给使用数组的客户带来麻烦,因为他们很难记住数组的第一个元素是姓名,

『重构--改善既有代码的设计』读书笔记----Inline Temp

与Inline Method相同,有时候犹豫需要Extract Method,需要对一些临时变量进行内联,而这个往往是Replace Temp with Query的一部分.简单来说,当你看到这种 double basePrice = anOrder.basePrice(); return (basePrice > 1000); 对于这种情况,basePrice完全是多余的变量,完全可以用函数本身来替代他.这里有个小窍门,你要内联这个变量,你必须要保证函数之后没有对这个变量进行过写操作,换句话说

『重构--改善既有代码的设计』读书笔记----Introduce Explaning Variable

有时候你会遇到一系列复杂的表达式连续运算的时候,这个时候你可能根本招架不住如此长或者是如此复杂的长函数.这个时候你可以通过引用临时变量来储存他们的结果,将这些长函数的结果分成一个个临时变量来让函数清晰化.但在这里,我的想法与作者的想法是一样的,我会更倾向于去用Extract Method去将复杂函数弄清晰,而尽量不去Introduce Explaning Vaiable,因为Extract Method优点很多,除了不增加临时变量增加函数长度之外,他的生命周期也比临时变量来的长,他可以让类中的所

『重构--改善既有代码的设计』读书笔记----Extract Method

在编程中,比较忌讳的一件事情就是长函数.因为长函数代表了你这段代码不能很好的复用以及内部可能出现很多别的地方的重复代码,而且这段长函数内部的处理逻辑你也不能很好的看清楚.因此,今天重构第一个手法就是处理长函数--Extract Method,抽取成一个独立的小函数. 我个人来说也很喜欢短小函数,因为他们代表了高强度的复用与灵活性.对于短小函数来说最最关键的就是短小函数的命名,其实你就是给了这些短小函数自我解释的机会,所以你如果给这些短小函数起一个接近其语义的名字,那当你读起长函数来说,就像是阅读

『重构--改善既有代码的设计』读书笔记----Change Value to Reference

有时候你会认为某个对象应该是去全局唯一的,这就是引用(Reference)的概念.它代表当你在某个地点对他进行修改之后,那么所有共享他的对象都应该在再次访问他的时候得到相应的修改.而不会像值对象(Value)一样,不可修改.举个例子,你认识小明,我也认识小明,小明忽然把头发都踢了,这个时候你认识的小明和我认识的小明都是同一个人,都是光头,这个小明就是世界的唯一实例,然而,你有100块钱,我有50块钱,我把50块钱花到只剩20,你手里的100块钱并不会因为我的50块钱改变而改变,不会相应的修改,这

『重构--改善既有代码的设计』读书笔记----Move Method

明确函数所在类的位置是很重要的.这样可以避免你的类与别的类有太多耦合.也会让你的类的内聚性变得更加牢固,让你的整个系统变得更加整洁.简单来说,如果在你的程序中,某个类的函数在使用的过程中,更多的是在和别的类进行交互,调用后者或者被后者调用,那么你就要注意了,你要去判断这个类是否真正适合他原来所在的类. 简单来说,这套手法就是在该函数最常引用的新类中建立一个有着类似行为的新函数,让旧函数变成一个单纯的委托函数或者完全删掉. Move Method是重构理论的支柱.如果一个类的责任太多,或者一个类和

『重构--改善既有代码的设计』读书笔记----代码坏味道【3】

星期六了,适当出去放松了下,回来继续我们重构的话题.今天是坏味道[3]了,很多朋友跟我私信,叫我把坏味道出完,再出手法.其实这是有道理的,很多时候,"发现"远比"怎么做"重要的多.就拿设计模式来讲,GoF里面的设计模式相信有很多人都了解过.具体的设计模式应该怎么实现啊相信有很多人都背的滚瓜烂熟,但问题的难点往往在于你应该什么时候用这个设计模式.重构也一样,手法步骤都是死的,关键在于应该发现什么时候应该重构.所以,我还是决定继续出坏味道,把坏味道全部出完我们再去学手法