重构与设计解析(非原创)

现行系统中我们存在的问题：

僵化性（Rigidity）：设计难以改变。

脆弱性（Fragility）：设计易于遭到破坏。

牢固性（Immobility）：设计难以重用。

粘滞性（Viscosity）：难以做正确的事情。

不必要的复杂性（Needless Complexity）：过分设计。

不必要的重复（Needless Repetition）：过多的重复。

晦涩性（Opacity）：混乱的表达。

 

具体来说：例如 

1、代码重复；
2、过长的方法（太多的上下文信息，如大量临时变量，使代码不容易理解）；
3、过大类（往往是一个类承担了太多的职责所致）；
4、过长参数列（方法参数一般不要超过7个）；
5、发散式变化（一个类受多种变化的影响）；
6、散弹式变化（一种变化引发多个类的相应修改）；
7、依恋情结（类的某个方法“身在曹营心在汉“）；
8、数据泥团（总是绑在一起的数据）；
9、基本类型偏执（过份依赖于语言内置的类型）；
10、Switch语句（容易导致重复）；
11、平行继承体系（散弹式变化的特例）；
12、冗赘类（一个类承担的职责过少）；
13、夸夸其谈未来性（过分追求代码的灵活性导致很多不必要的事情，增加了系统理解难度和可维护度）；
14、令人迷惑的暂时值域（值域“招聘了临时工”）；
15、过度耦合的消息链（对象之间玩起了“击鼓传花”）；
16、中间转手人（一个类里有过多“不干实事”的方法）；
17、狎昵关系（两个类过于亲密）；
18、异曲同工的类（“马甲”类）；
19、不完美的程序库类；
20、纯稚的数据类（“哑类”，“只吃粮食不干活”的类）；
21、被拒绝的遗赠（这个气味一般不强烈）；
22、过多的注释（感觉需要添加注释前试着让所有注释都变得多余）。

 

重构(Refactoring)

在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构一种有纪律的、经过训练的、有条不紊的程序整理方法。

本质：在代码写好后改进它的设计

 

重构与哪些技术有关系： 设计模式 类设计 系统架构 

设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

类的设计：  单一职责原则（SRP） 开放-封闭原则（OCP） Liskov替换原则（LSP） 依赖倒置原则（DIP） 接口隔离原则（ISP）

就一个类而言，应该仅有一个引起它变化的原因，一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。

系统架构的设计 面向组件或是面向服务

下面有时间结合实际项目给大家介绍下我的重构过程。