《重构：改善既有代码的设计》读书笔记

??如果1个人没有听说过《重构》这本书，那末他1定不敢说自己是程序员；如果1个人没有浏览过《重构》这本书，那末很难想象他会是1名优秀的程序员。这本书是很多公司要求Java程序员必读的3本书之1（另外两本书是《Java编程思想》和《Effective Java》），其实无关编程语言，是程序员就可以够从这本书中受益。
??何谓重构？重构是对软件内部结构的1种调剂，目的是在不改变软件可视察行动的条件下，提高其可理解性，下降修改本钱。重构是用微小的步伐修改程序，在这个进程中也能够很容易的发现程序中的毛病。重构的时机可以是添加功能时，也能够是修补毛病时，还可以是复审代码时。重构的目标是让代码容易浏览、所有逻辑都在唯1地点指定、新的改动不会危及现有行动、尽量简单的表达逻辑。
??这本书我个人最喜欢的第3章 - “代码的坏味道”，由于我喜欢在写完代码后去思考我的代码中有无这些坏味道，然后再去想想应当如何重构代码。这本书的作者是世界级的软件开发大师Martin Fowler，他也被誉为软件开发“教父”，同时他还是敏捷开发的开创人之1。Martin Fowler编写了很多极好的书籍，包括《企业利用架构模式》、《领域特定语言》、《NoSQL精粹》、《分析模式：可重用对象模型》等。Martin Fowler给出的代码的坏味道包括：
- Duplicated Code（重复代码）：“代码有很多中坏味道，重复是最坏的1种”，这句话我常常讲给自己的学生听，但是他们真正领悟并践行这句话的人却不多。1个类中的两个方法有重复代码，那末1定可以通过抽取方法的方式将重复代码放到另外一个方法中以供调用；两个互为兄弟的子类中如果有重复代码可以将其重复代码抽取到父类中；两个没有关系的类中如果有重复代码，那末可以重新抽取1个类将重复代码放到这个第3方类中。
- Long Method（长的方法）：程序越长理解起来就越困难，这已是常识了，使用短小的方法首先符合高内聚的要求，同时也能够给通过给方法起1个好的名字来帮助理解方法的作用。如果感觉到方法的某个地方需要注释来讲明甚么，那末可以把这些东西放入1个独立的方法中，并以用处（注意不是实现手法）来命名方法。
- Large Class（巨大的类）：如果希望写1个类来做很多的事情，那末终究必将致使重复和混乱的代码。类的设计应当遵守单1职责原则（SRP）。重构1个巨大的类可使用抽取接口的方式来弄清楚这个类应当如何分解。
- Long Parameter List（长参数列表）：这个对做过Windows编程或用过MFC（Microsoft Foundation Class）的程序员来讲再熟习不过了，Windows函数和MFC中的方法那些长得变态的参数列表对程序员来讲都是噩梦。重构的方式很多，比较常见的是将相干的参数组织成1个对象来替换掉这些参数。
- Divergent Change（分散的可变性）和Shotgun Surgery（散弹式手术）：这两种坏味道前者讲的是新功能难以加入，后者说的是某种变化会引发多个细节的修改。简单的说如果程序中的可变因素散落在代码的各个角落中，那末代码的保护将是1场噩梦。重构的方法是找到特定缘由酿成的所有变化，然后将它们抽取到另外一个类中。设计模式中的桥梁模式就是为了解决这1问题而提供的解决方案。
- Feature Envy：这个真没想到如何翻译会比较容易理解，简单的说就是1个方法从另外一个类的对象那里获得许多的值，重构的方案是将该方法移到另外一个类中。听起来很简单，但是在实践的时候却常常会忘了这么做。
- Data Clumps（数据群集）：状态类似于长参数列表。
- Primitive Obsession（基本类型偏执）。1个类中如果有很多基本类型的成员，通常可以斟酌将不同的基本类型分散组装成对象，就像Hibernate中的组合映照那样，将1个类的对象嵌入到另外一个类中作为其成员而不是只写1个类，里面有很多基本数据类型的成员。
- Switch Statements（重复的switch语句）：面向对象程序的1个明显特点就是用多态替换掉switch结构，由于这类switch结构会在多个地方重复。
- Parallel Inheritance Hierarchies（平行继承结构）：情况跟Shortgun Surgery差不多，可使用桥梁模式进行重构。
- Lazy Class（冗余类）：如果1个类不值得存在，那末它就应当消失。
- Speculative Generality（投机通用性）：如果你的抽象类、拜托、方法的参数没有实际的作用，那末就应当被移除掉。
- Temporary Field（临时字段）：类中某个字段只为某些特殊情况而设置。
- Message Chains（消息链）：我个人并没有感觉到这个有多么坏。
- Middle Man（中间人）：如果1个类的很多功能都通过拜托给其他类来完成，那末就不如去掉这些中间人直接和真正负责的对象打交道。
- Inappropriate Intimacy（过于密切）：使用继承复用代码会常常性的引发这类问题，由于子类对父类的了解总是超过后者的主观欲望，如果你觉得这个孩子可以独立生活了，就应当让它离开继承体系，这1点跟面向对象设计原则中的合成聚合复用原则不谋而合。
- Alternative Classes with Different Interfaces（异曲同工）：两个方法做同1件事情却有着不同的签名。
- Incomplete Library Class（不完全类库）。
- Data Class（数据类）：类的退化结构。我们在分层开发中常常使用的失血模型（事务脚本模式）中的业务实体不就是数据类吗，这明显与面向对象的思想是背道而驰的。
- Refused Bequest（谢绝遗产）：如果子类复用了父类的行动，又不愿意支持父类的接口，可以斟酌用合成关系聚合关系取代继承关系来消除这类坏味道。
- Comments（注释劣质代码）：注释不是用来补救劣质代码的，事实上如果我们去除代码中的所有坏味道，当劣质代码都被移除的时候，注释已变很多余，由于代码已讲清楚了1切。

??完全根除代码中这些坏味道的方法在《重构》1书的第6章到第102章，提供了约70条重构建议，其中1部份经常使用的重构建议在IDE的重构菜单中也能找到。Eclipse和IntelliJ的重构菜单分别以下面两张图所示。
Eclipse的重构菜单：

IntelliJ的重构菜单：