《重构:改善既有代码的设计》读书笔记（持续更新中）

背景（我也不知道这个算不算读书笔记，书本知识点整理和个人理解内容可跳至下面正文）：

最近过年加找工作一直没想起来整理学习内容， 时间都很零碎。回想一下， 的确一直以来都是为了完成项目去看知识点。 除了刚开始想转行做IT的时候跟着慕课网的两条前后端路线系统地学习了一下， 但是终究囫囵吞枣。

前几天刚好有被问到《重构》这本书的内容。这两天临时抱佛脚看一下。 有了一定量的代码量积累的现在， 带着些许疑惑和朦胧的概念， 刚好到了看这本书的时候。

其实再上一家公司， 很早以前就被推荐这本书了， 不过不知道为什么后来忘了。 现在稍微看了下， 突然发现， 之前被要求我做到的一些代码习惯和公司内部的代码风格很多都能在书中找到。有些写代码的时候遇到的疑惑在书中也有提到（经常一边写新代码一边看之前的代码，尽量优化，奈何水平太菜， 经常迷茫于如何取舍，甚至最开始有段时间为了代码的简短和重复使用用力过头），感谢同事一直以来的帮助和容忍（我写的屎山和比蜗牛快不了多少的代码速度）。

在这个迷迷糊糊但是有点头绪的时候看这本书， 是最好的。

===========================================================================================

正文：

关于面向对象的五大原则：

1. 单一职责： 一个类只负责一个职责。 目的在于解耦增强内聚。
2. 开闭原则：对于扩展是开放的，对于修改是关闭的。可利用多态、抽象类等实现扩展，超类不应该做改变。
3. 里氏替换原则：子类必能代替父类。
4. 依赖倒转原则：高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象；抽象不应该依赖于具体实现，具体实现应该依赖于抽象
5. 接口隔离原则：一个类对另一个类的依赖应该建立在最小的接口上，使用多个专门的接口比使用单一的总接口要好
6. 迪米特原则（最小知识原则）：一个对象应当对其他对象有尽可能少的了解。

所以， 在开发过程中， 我们的目标是：复用性、重构性、维护性。这本书很多地方都是以这三个目标为中心， 以求养成良好的代码风格和代码习惯。

----------------------------------------------------------------------------------------------------------

第一章：

这一章主要是用一个案例简单引出了一个重构的大概形象。

读这一章的时候我反思对比了一下以前开发过程中经历。如果有时间， 可以尝试下自己如何重构再对比下作者的做法

第一点我注意到的是， 重构需要以微小的步伐进行修改程序， 可以多次修改， 但是切忌不能一次性把一大段修改掉， 很容易出错。刚开始的时候我会犯这种错误， 心太急， 直接把整段代码拷贝出来， 有时候会把中间有些引入的参数或者被修改的参数（特别是Java传对象时引用传递，原对象会被不小心改掉）遗漏引发不必要的bug。所以在每一步的修改后都阶段性进行测试都是必要的。

所在在看到第一章的内容时如觉醍醐灌顶：在提取代码前， 首先我们必须 找出函数内局部变量和参数，未被修改的作为传入值， 被修改的作为返回值。 但是要注意的是被修改的参数尽量要少。

有一点之前我没想到过的是：只涉及某个类的方法， 写到该类下， 使用return返回该方法。 这个一般在第一遍写的时候就决定了代码放在哪个类， 但是在后期多次修改后的确会出现这个方法可能和其它类关系密切点的情况， 但是我不会去注意到需要移动他（也有一部分怕出错吧， 毕竟要是换了地方会引起其它地方拿不到， 越是到后期越是难以动这些代码， 涉及的东西太多， 修改非常容易出现遗漏， 工作量也很大）。

然后第一章的示例中还提到了变量的问题，感谢老大， 这方面之前没有问题，我们的代码中：

1. 引入参数以a开头，方法内变量名以类型首字母小写开头， 但是成员变量不加类型首字母， 自动生成get/set的方法时会出问题。

2. 类名采用名词，方法名采用动词加名词的格式，且不能以is/get/set开头，这些会和部分框架之类的冲突， 尽量避免。 类似增删改查固定功能的方法名会以特定单词和格式，所有代码统一。

3. 工具类的构造方法时静态的， 以防被实例化， 下面的方法采用静态方法。不