美文网首页TDD(测试驱动开发)
[RedRain笔记] - <重构与模式> 各章简介

[RedRain笔记] - <重构与模式> 各章简介

作者: rxdxxxx | 来源:发表于2016-07-24 21:51 被阅读79次

RedRain的简书:http://www.jianshu.com/users/29e03e6ff407/latest_articles

一.创建

1. 如果类中有太多的构造函数,客户要弄清应该调用其中的哪一个会非常困难.

  • 方法之一是应用提炼类提炼子类这样的重构, 减少构造函数的数量.
  • 方法之二是通过用Creation Method替换构造函数重构来澄清构造函数的意图.

2.如果对象创建过程中使用的数据和代码在许多类中都存在

  • 将创建知识搬移到Factory重构可以把创建代码和数据合并为一个Factory来减少创建代码的蔓延.

3.如果类层次中有多个类都类似地实现了一个方法, 只是对象的创建步骤不同

  • 首先通过用Factory Method引入多态创建重构来删除重复代码.

4.确保客户代码通过一个公共接口与多个类的实例进行通信

  • Factory封装类

5.简化对象结构的构造

  • 用Builder封装Composite重构说明了如何用Builder模式提供构造Composite模式的更简单而且不易出错的方式.

二.简化

为了使代码简单,必须要思考它复杂在什么地方, 并要不停地问:"怎样能更简单一些?"

通常情况下, 可以考虑一种完全不同的解决方案来简化代码. 这里展示了简化方法,状态转换树型结构的不同方案.

1.更有效地表达方法实现的功能以及如何实现这些功能

  • 组合方法重构用来生成更优雅的方法
  • 一个组合方法由对一些命名良好的方法的调用组成
  • 这些方法数据实现细节的同一个曾铭.

2.算法经常会因为多种变化而变得复杂

  • Strategy替换条件逻辑重构展示了如何通过把算法分解成单独的类来简化它.
  • 如何算法并没有复杂到需要使用Strategy,只会使设计更加复杂

3.一个类中有过多的特殊情况或装饰逻辑

  • 将装饰逻辑搬移到Decorator重构描述了如何判断是否需要应用Decorator, 并展示了如何把装饰功能从类的核心职责中分离出来.

4.控制状态转换的逻辑往往会变得越来越复杂.

  • State替换状态改变条件语句重构描述了如何简化复杂的状态转换逻辑, 并帮助确定逻辑是否复杂到应该应用State模式

5.针对树型结构的重构方法

  • Composite替换隐含树, 展示了Composite模式如何能够简化客户程序对树形结构的创建和交互

6.完全简化一个用来控制哪组行为应该执行的switch语句

  • 用Command替换条件调度程序.

三.泛化

泛化是把特殊代码转换成 通用目的 代码的过程. 泛化代码的产生往往是重构的结果. 其最常见的动机就是去除重复代码, 其次是为了简化或澄清代码.

1. 去除同一类层次结构中子类所包含的相似方法中的重复代码.

  • Template Method重构,如果这些方法基本是遵循一定的步骤, 一定的顺序, 即使这些步骤有少许区别, 也可以通过在超类中定义Template Method把这些区别与泛化的内容分开

2.一个类层次结构中存在不恰当的Composite[组合]实现的时候.

  • 提取Composite重构是提炼超类重构的具体应用, 通过把Composite提取成超类, 子类就可以共享Composite的一个泛化实现.

3.如果系统含有处理一个对象代码, 同时又含有处理一组相同对象的代码(通常是某个集合).

  • Composite替换一/多之分重构可以帮助我们产生一个泛化的解决方案, 可以无差别处理一个或多个对象

4.负责通知的对象和被通知的对象紧紧的耦合在一起.

  • Observer替换硬编码的通知重构是用泛化替代特定方案的经典实例.为了允许其他类的实例也可以被通知, 我们可以把代码重构成使用Observer.

5.当客户代码使用不同的接口与相似的类交互时, 往往就会产生复杂的处理逻辑.

  • 应用通过Adapter[适配器]统一接口重构, 客户代码就可以通过一个泛化的接口与相似类交互, 这就为去除客户代码中重复处理逻辑的其他重构铺平了道理.

6.当一个类作为组件,类库,API或其他实体的多个版本的Adapter的时候, 这个类就会包含重复代码, 并且设计也不会简单.

  • 应用提取Adapter重构可以产生实现了通用接口并适配单一版本代码的类.

四.保护

有些重构能够改进对现有代码的保护, 但不能改变现有代码的行为. 应用这些重构的动机可能是改进对现有代码的保护, 或者是标准的重构动机, 如减少重复代码或简化澄清代码.

1.用类替换类型代码

2.如果想要控制一个类被实例化多个对象, 减少内存使用量或改进性能.

  • 用Singleton限制实例化.
  • Singleton模式的一个很不好的动机是使一段代码能够访问很难到达的信息. 一般情况下, 只有在性能分析程序告诉你值得这么做的时候,才会用到Singleton限制实例化

3.如果代码中包含很多的逻辑来检查相同的null值.

  • 引入Null Object重构可以帮助我们使用另一个方式让代码避免使用null值. 从而简化代码.

五.聚集操作

Collecting Parameter是这样一个对象, 他会访问不同的方法, 以便从中聚集信息, 被访问的方法可能处于一个或多个对象中. 每个被访问的方法都会为Collecing Parameter提供信息. 在访问了所有的相关方法之后, 我们就可以从Collecting Parameter中获取聚集的信息.

1.当你拥有一个很长的,包含很多行为来聚集信息的代码的方法时.

  • 利用将聚集操作搬移到Collecting Parameter重构与组合方法重构一起使用, 会达到最好的效果. 应该把接收并写入Collecting Parameter的代码提炼成方法, 这样就可以把原方法分解成几个小部分, 每一部分处理聚集的一小块.

2.Visitor模式

Collecting Parameter模式的能力是从几个对象中聚集信息, 从这一点上来看, 它和Visitor模式很相似. 不同的是

  • 被Visitor访问的对象把自己传入Visitor的实例.
  • 被Collecting Parameter访问的对象通过简单地调动Collecting Parameter上的方法来为它提供信息.

Visitor模式只适用于从多个对象中聚集信息, 而不适用于一个对象的情况. 它也更适用于从不同的对象中聚集信息, 而不适用于相似的对象(例如,共享相同接口的对象). 因为Visitor实现起来要比Collecting Parameter复杂. 所以要使用Visitor之前先考虑是否可以使用Collecting Parameter.

六.实用重构

1.使构造函数彼此调用,去除构造函数中重复代码.

  • 链构造函数, 这个重构会在用Creation Method替换构造函数重构中用到

2.当需要一个超类或接口来共享子类的相同接口时.

  • 统一接口重构就可以派上用场. 应用这一重构的通常动机是能够多态地使用对象. 重构将装饰功能搬移到Decorator将聚集操作搬移到Visitor都会使用到这一重构

3.一个字段被赋值为局部实例化的值, 而你更希望把这个值作为参数传递进来.

  • 使用提取参数重构. 这在很多情况下都是很有帮助的, 尤其是将装饰功能搬移到Decorator重构, 他会在应用了以委托取代继承重构后, 马上使用这一重构.

相关文章

网友评论

    本文标题:[RedRain笔记] - <重构与模式> 各章简介

    本文链接:https://www.haomeiwen.com/subject/wnkgjttx.html