优雅编程之这样重构代码，你就“正常”了（十八）

开心一笑

【老婆问老公：你喜欢玩水还是喜欢玩火？

老公：我喜欢玩火。

老婆：那以后，饭就由你来煮。

老公：不不不，我喜欢玩水。

老婆：那以后的碗就由你来洗。

老公：瞬间石化。…】

【男孩：我感动天，感动地，怎么感动………

女孩：你要是敢动我，我，我，我就打死你。

男孩：好好的一首情歌。……】

视频教程

大家好，我录制的视频《Java之优雅编程之道》已经在CSDN学院发布了，有兴趣的同学可以购买观看，相信大家一定会收获到很多知识的。谢谢大家的支持……

视频地址：http://edu.csdn.net/lecturer/994

提出问题

项目开发中如何进行重构？？？

解决问题

这是《重构 改善既有代码的设计》中第1~5章我觉得比较重要的知识点。事实上只要看第1章的例子，第2~4章个人建议可以略过，没什么用.

重构的第一步

每当我要进行重构的时候，第一个步骤永远是相同的。即建立一个可靠的测试环境。

分解和重组

代码块越小，代码的功能就越容易管理，代码的处理和移动也就越轻松。

首先，我得在代码里找出函数内的局部变量和参数。任何不会被修改的变量，都可以被我当成参数传入新的函数，至于会被修改的变量，就需要格外的小心。

正和一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解代码才是优秀的程序员。

去除临时变量

利用多态取代

何为重构：

名词：重构，对软件内部结构的一种调整，目的是在不改变，软件可观察行为的前提下，提高其可理解性，降低其修改成本。

动词：重构，使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

两顶帽子

添加新功能以及重构。

添加新功能就添加新功能，先不要去重构，重构你就好好重构，先不要去添加新的功能。

为何重构

原因我就不说了，反正就他妈好。

何时重构

三次法则：第一次做某件事时只管去做，第二次做类似的事时会产生反感，但无论如何还是可以去做，第三次再做类似的事，你就应该重构。

添加功能时重构

修补错误时重构

复审代码时重构

以下是一些坏代码味道：符合下面就该重构了

Duplicated Code(重复代码)

Long Method(过长函数)

Large Class（过大的类）

Long Parameter List（过长的参数列表）

Divergent Change（发散式变化）：当你看着一个类说：如果新加入一个数据库，我必须修改这三个函数，如果新出现一种金融工具，我必须修改这四个函数。那么此时也许将这个对象分成两个会更好。

Shotgun Surgery(弹式修改)：

如果遇到哪种情况，你都必须在很多不同的类内作出，许多小修改。那就是坏的味道。这时候你需要把所有需要修改的代码放进同一个类。如果眼下没有合适的类可以安置这些代码，就创建一个。

Feature Envy（依恋情节）

函数对某个类的兴趣高过对自己所处类的兴趣，是时候考虑这个函数到底应该放在什么位置了。

对象技术的全部要点：这是一种将数据和对数据的操作行为包装在一起的技术。

最根本的原则是，将总是一起变化的东西放在一块。

数据和引用这些数据的行为总是一起变化的。

Data Clumps（数据泥团）

减少字段和参数的个数，当然可以去除一些坏味道。但更重要的是，一旦拥有新对象，你就有机会让程序散发出一种芳香。

Primitive Obsession（基本类型偏执）

将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。

编写小对象，如表示范围的Range

Switch Statements(switch 惊悚现身)

面向对象程序的一个最明显特征：少用switch（或case）语句。

看到switch语句，就应该考虑以多态来替换它。

Parallel Inheritance Hierarchies（平行继承体系）

每当你为某个类添加一个子类，必须也为另一个类相应增加一个子类，大多数时候你会发现，某个继承体系的类名前缀和另一个继承体系的类名前缀完全相同。是时候分离，为两个继承体系了。

Lazy Class（冗赘类）

你所创建的每个类，都得有人去理解它，维护它，这些工作都是要花钱的。如果一个类的所得不值其所价，它就应该消失。

Speculative Generality（夸夸其谈未来性）

无用的抽象类，无用的预留参数。

Temporary Field（令人迷惑的暂时字段）

某个类的实例变量仅为某种特定情况来设，某个函数的参数，为了方便声明为某个类的成员，而仅仅在这一个函数中使用。

Message Chains（过度耦合的函数）

现一个对象请求另一个对象，在向后者请求另一个对象。

Middle Man（中间人）

你也许会看到某个类接口，有一半的函数都委托给其他类，这样就是过度运用。

无用的委托，过多的中间层。

Inappropriate Intimacy(钾昵关系)

类不要过度亲密，一个类过一关注另一个类的成员。

Alternative Classes with Different Interfaces(曲同工的类)

两个函数做同一件事，却有着不同的类名

Incomplete Library Class(不完美的类库)

Data Class（纯稚的数据类）

或许可以通过移动方法把和这个数据对相关的操作一过来。

Refused Bequest（被拒绝的遗赠）

Comments（过多的注释）

读书感悟

来自几米《月亮忘记了》

每个人都有一个像月亮一样的爱人，因为这个爱人，我们拥有守护的能力。

记住的，是不是永远不会消失？ 我守护如泡沫般脆弱的梦境， 快乐才刚开始，悲伤却早已潜伏而来。

生命中，不断地有得到和失落。于是，看不见的，看见了；遗忘的，记住了。

生命中，不断地有人离开或进入。于是，看见的，看不见了；记住的，遗忘了。

然而，看不见的，是不是就等于不存在？记住的，是不是就不会消失？

其他

如果有带给你一丝丝小快乐，就让快乐继续传递下去，欢迎转载，点赞，顶，欢迎留下宝贵的意见，多谢支持！