Refactoring_Improving_the_design_of_existing_code--笔记

chapter-1

• 例子1：
  
  1. 方法a(){根据不同类型电影，租期长短，计算价格，并输出}
  2. 可能变化：增加/改变输出样式，电影类型分类可能会变，计费标准会变。
• 只有优秀的人才能写出人易读的代码。机器永远会理解。
• 方法/变量名称，是代码清晰的关键。

• 方法应该放在，它使用的数据所属对象内，这样依赖低

• 例子2：

  1. 一个电影可以在生命周期内修改分类，一个对象却不能修复所属类。
  2. 不能创建电影子类，但可以创建价格子类。replace type with state/strategy,
  3. 把type相关行为移到state/strategy内部。
  4. 模式取决于：state:代表电影的某个状态，strategy代表计费策略。反映对结构的想法。

• 面向对象：思考对象的职责。

• 重构可以取代预先设计（不要过度设计，简单即美），重构随时随地。
• 重复是万恶之源。事不过三，三则重构。switch意味着重复，少用

chapter-6

• extract method的判断标准：以它“做什么”命名，不是怎么做。
• replace temp with query ：以查询方法代替临时变量，临时变量时局部的，为了使用它，它会驱使你写更长的方法

double getPrice(){ //两个临时变量    const int basePrice = m_quanity * m_itemPrice;    double discountFactor;    if (basePrice > 1000){        discountFactor = 0.95    }else{        discountFactor = 0.98    }    return basePrice * discountFactor;}//用方法替换临时变量double getPrice(){    return basePrice() * discountFactor();}int basePrice(){    return m_quanity * m_itemPrice;}double discountFactor(){    if (basePrice() > 1000){        return 0.95    }else{        return 0.98    }}

• introduce explaining variable 解释性变量

 if( (platform.indexOf("MAC") > -1) && isIEBrower){...}  //替换成 boolean isMacOs = platform.indexOf("MAC") > -1; if( isMacOs && isIEBrower){...}    

chapter-7

• 如果一个类承担太多责任，考虑extract class,如果只有这个类使用新类，考虑inline class

chapter-8

• 状态码
  
  1. 不变、且行为相同，不用抽取。比如性别男女。
  2. 不变、行为不同，抽取子类。
  3. 可变，生命周期内可变、或其他原因不能继承，使用state/stratege模式

chapter-9 简化方法调用

• 查询、修改方法分离。getTotalAndSetSum()–>getTotal(),setSum();
• 参数超过4个时，使用对象封装参数。
  
  1. 一个业务类，查询对象可以有多个类，不要包含无用的属性，那会带来理解困难。
  2. netty的网络配置项，有很多属性，但是提供了默认值，即使不设置也没问题。
• 工厂方法：根据类型码，提供一组类的，对象构造方式。接口简单统一。
• 如果有向下转型的代码，首先考虑是否可以用模板类代替。
• 不恰当的继承，改用组合：
  
  1. 超类中许多方法并不真正适用于子类，子类通过父类获得的接口并未真正反映出子类的功能，意图混淆
  2. 从超类中继承了一大堆子类并不需要的数据
  3. 你可能发现超类中的某些protected函数对子类并没有什么意义。
• 不恰当的组合，改用继承
  
  1. 需要使用受delegation的类的所有方法时，改为继承。
• 类内部field自我封装：直接使用变量，直到它带来麻烦为止，自我封装是方便子类覆盖。
• replace data value with object 把电话号码抽取成对象，因为有格式化，抽取区号，等方法