《重构》第五、六章 - 常用的重构方法推荐？

书中每个章节都推荐了大量的重构手段，当开发者在面对大量无论是已经熟悉的还是新了解的重构手段时，如何快速的回忆并且选择更高效的方式进行重构？ 对于这个问题书中推荐了一种重构记录方式:

采用从名称、速写、动机、做法以及范例五个方面进行记录。

下面通过文字的方式记录作者常使用的几种重构方式：

提炼函数

• 动机

  什么时候该提炼函数？

  当声明与实现不同时，这时候导致再次开发时需要通过注释+代码逻辑才能明白用途时，需要提炼出函数。举例: 函数名声明为highlight（高亮），但是实现逻辑是调用了reverse方法，再setColor:等行为，这样会导致声明和实现之间有相当大的距离。

  一行代码的短函数 vs 性能？

  有些人会担心短函数会造成大量函数调用，栈内层级的增加会影响运行的性能，但是现有硬件的支持这种影响其实已经可以忽略；而且短函数常常能让编译器的优化功能运转更良好，因为短函数可以更容易的被缓存，所以不用过早的担心性能问题

  总结：当发现某段代码需要注释才能被理解用途时（声明与实现存在差异），就该主动的提炼函数。

• 做法

  1.函数命名： 在提取逻辑上写上关于本段代码用途描述的注释，然后通过注释翻译成函数名。无需计较命名不准确的问题，因为函数名不是一蹴而就的，而是随着理解的不断加深和上下文的变化，不断的更新的。

  2.参数列表: 提取的代码逻辑中的参数，如果只有该部分使用那么可直接提取成一个 参数查询的函数；如果不止该部分代码中使用，那么可以作为函数入参传递进来。

  3.上下文中替换并测试: 重构应该是一小步一小步的前进，每次有代码修改都应该及时编译测试。

内联函数

• 动机

  经常以简短的函数表现动作意图，这样会使代码更清晰易读；但有时候遇到的某些函数，其内部代码和函数名称同样清晰易读，这时候应该去掉这个函数直接使用其中的代码；毕竟非必要的间接性使用总是让人不舒服的（因为会导致开发时阅读总跳来跳去的！！）

• 范例

- (void)getRating:(Driver *)driver {
    return [self moreThanFiveLateDeliveries:driver] ? 2: 1;
}

- (BOOL)moreThanFiveLateDeliveries:(NSInteger)driver {
    return driver.numberOfLateDeliveries > 5;
}

以简单的例子解释，moreThanFiveLateDeliveries: 函数名作为中间层并没有为原来的逻辑增彩，无任何的价值，所以这时候可以直接将函数去掉直接使用实现中的代码:

- (void)getRating:(Driver *)driver {
    return driver.numberOfLateDeliveries > 5 ? 2: 1
}

• 注意

  1.当函数在多个位置使用时，在移除时需找到所有的调用点进行替换；

  2.移除函数定义的前提是函数内部实现已足够清晰易读，能直接表达出 函数名 所表达的意义；在处理一些复杂情况时就不要使用该重构方法！！

提炼变量（Extract Variable）

• 动机

  当表达式较复杂难以阅读时，局部变量名可以帮助更好的理解开发者想表达的意图；并且作为开发者定义变量名也能在调试时提供更便利的操作（比如 ex (方法名) = (新定义行为)等）。

• 范例

- (CGFloat)price:(Order *)order {
    return order.quantity * order.itemPrice - Math.max(0, order.quantity - 500) * order.itemPrice * 0.05 + Math.min(order.quantity * order.itemPrice * 0.1, 100);
}

在阅读以上函数内容时，虽然使用的参数较少、命名规范，但是短时间内还是无法明白其中计算逻辑，所以如果将表达式赋值给局部变量：

首先  order.quantity * order.itemPrice = 底价
其次 Math.max(0, order.quantity - 500) * order.itemPrice * 0.05 = 批发折扣
最后  Math.min(order.quantity * order.itemPrice * 0.1, 100) = 运费
通过定义参数名，针对每个变量加一些业务注释，就能更好的理解这段代码：
CGFloat basePrice = order.quantity * order.itemPrice 
CGFloat quantityDiscount = Math.max(0, order.quantity - 500) * order.itemPrice * 0.05
CGFloat freight = Math.min(basePrice * 0.1, 100)

最终代码呈现：

- (CGFloat)price:(Order *)order {
    // 底价
    CGFloat basePrice = order.quantity * order.itemPrice; 
    // 批发折扣
    CGFloat quantityDiscount = Math.max(0, order.quantity - 500) * order.itemPrice * 0.05;
    // 运费
    CGFloat freight = Math.min(basePrice * 0.1, 100);
    return basePrice - quantityDiscount + freight;
}

内联变量

• 动机

  变量名的定义是为了给表达式提供更具有理解性、更有意义的名字，但是有时候名字反而会妨碍到上下文的代码，影响理解，这时候就应该消除变量。

• 范例

NSInteger age = lizhou.age;

这种局部变量毫无价值，应使用该重构方法去除。

改变函数声明

• 动机

  函数名命名方法？

  函数名是在理解的不断加深和上下文的变化中，不断更新改名以此来更清晰的表达这块代码的用途（在开发中一旦发现有更好的命名应该尽快为函数改名！）。

  函数的入参如何考虑？

  函数的参数列表阐明了函数如何与外部世界共处，也就是我们在定义函数时需要明确函数的上下文，只有在这个上下文中才能使用该函数；由于参数列表是改变连接一个模块所需的条件，所以需要不断的去除不必要的耦合。

  结论：如何定义正确的函数名？如何定义核实的入参列表？这都是没有正确答案的，因为答案会随着时间变化；所以掌握这种重构方法，在对代码理解加深的过程中一步一步的重构。

• 范例

@interface TopModel: NSObject 
@property (nonatomic, strong) NavModel *nav;
@property (nonatomic, strong) contentModel *content;
@property (nonatomic, strong) BottomModel *bottom;
@end

1.改变参数列表：定义合适的范围

- (void)bindData:(TopModel *)model {
    // 内部只使用了TopModel中的nav 和 bottom中的A个字段
    // 从某种意义上来说，可以只传递 nav 和 bottom中的 A字段
    // 在开发递进的过程中，当参数不断增加后可以自定义独立的Model，但是一次性将顶层的 TopModel 传递进来，反而限制了这个类的使用范围
}

2.当修改某个方法名或参数列表后，应该使用 deprecated 标注，而不是直接删除。等到版本升级一段时间后再进行移除。

- (void)bindData:(TopModel *)model __attribute__((deprecated))；
- (void)bindData:(NavModel *)nav withA:(NSString *)A;

引入参数对象

• 动机 当一组数据总是结伴出现时，可以通过定义一个新类型的Model进行处理。这项重构真正的意义在于：会让代码具有更明确的界限！

• 范例

@interface NavModel: NSObject 
@property (nonatomic, strong) NavLeftModel *left;
@property (nonatomic, strong) NavRightModel *right;
@property (nonatomic, strong) NavCenterModel *center;
@end
@interface TopModel: NSObject 
@property (nonatomic, strong) NavModel *nav;
@property (nonatomic, strong) contentModel *content;
@property (nonatomic, strong) BottomModel *bottom;
@end

在传递时，有多个地方使用AView，传递的数据较多但是数据结构不尽相同时，为了提高AView的复用性这时候可以定义AModel来封装所有需要传递的字段。

@interface AModel: NSObject 
// 自定义需要的字段
@end

使用这种方法重构会导致更深层次的改变，也就相当于开发者只要在使用该类时就需要将自己持有的数据结构转换成AModel的格式，当然如果AModel中字段定义存在歧义，那么就达不到想要的效果。所以开发者应尽可能的增加通用化数据结构设计！