重构心路历程：如何做好抽象与设计？

自“重构”一词被Martin Fowler在上世纪末提出以来，一直受到诸多软件开发人员的追捧，圈内人若是对重构不大关注，似乎是有些数典忘祖的意味。于是乎，圈内人无论自身水平如何都开始关注重构，开始动手“去做”；至于做得好不好，结果合理与否，很难有事实标准去衡量。

越来越多的“网红重构”

Martin Fowler在写《重构》一书时，明确提出了重构的几个目的:

• 改进设计
• 使得软件更易被人理解
• Find Bugs
• 提高开发速度

可见重构的起点很明确--改进设计，OOP的出现为“软件设计“赋予了更深层的定义：”高内聚、低耦合“无人不知，无人不晓，可以被用于很多领域的设计工作上；然而对SOLID理解透彻的软件从业人员又有几何？

重构不是一时冲动，也不是为了达成特定的业绩目标。我更希望它能够成为软件从业人员自身的基本素质，不必时时刻刻挂在嘴边。重构的特殊性使得其价值体现有很长的延迟，只有出于本能的重构才是纯洁的，如果带有任何利益相关的目的性，那么这个重构就是有污点的。

如何改进设计？

业务是根本。不论是多复杂的软件，其根本目的都是为了实现人的业务需求，因此软件世界与真实世界有很多的相似性。关键过程就在于，我们如何把人的需求翻译成软件模型呢？

UML的出现为软件设计领域提供了事实标准，我们开始了解到了参与软件系统的一些关键角色；以及这些角色的依赖关系，甚至开始关注这些角色的状态变更。于是我们发现“抽象”极其重要，对于一个经常变化的业务需求，我们需要关注这些要点：

• 基本流程和处理步骤是什么？
• 有哪些关键角色参与了这个流程？
• 这些角色自身有什么特点（属性）？
• 这些角色是如何协同、合作（依赖、组合...关系）的呢？
• 角色是否会发生状态变化（状态图）？

弄清楚了以上的内容，就可以按照UML标准给出一系列的设计图，用于说明你的设计意图（此处不建议其他的表达形式，鉴于UML已经足够成熟和被认可），但这个设计意图并不一定是最优解。

抽象与模式

OOP的魅力就在于抽象与复用，抽象其本质是分离稳定不变的点，而复用则是为了应付软件系统的复杂性，提供足够的灵活性来扩展软件系统。任何软件系统与真实世界必然存在联系，我们不妨先脱离软件设计本身的理论，仅考虑真实世界的类似场景，看看这个场景中存在哪些不变的参与者。

例如，我们在超市购物时，通常会有这样的场景：找到一辆购物车->选购商品->往收银台结算->付款打印小票。对应的，如果将这套业务搬到软件系统中，我们就会发现一些稳定出现的参与者：顾客（Customer），购物车（ShoppingCart），商品（Product），订单（Order），交易（Transaction），小票（Receipt）。
再深入探究一下这些参与者的行为特征：顾客通常会找购物车，会浏览商品信息选择是否购买，结账时支付订单；购物车就比较单纯，只负责装添加的货物；商品能够展示价格和基本信息；顾客推购物车去结算的时候会产生订单，结算时就完成了一笔或多笔交易，交易完成以后顾客就拿到了小票。把这些参与者的行为特征（业务方法）和自身属性组合起来，我们就有了软件系统中对应的一个角色，通常我们把它称之为“领域对象”（Domain Object）。

完成抽象之后，进一步关注这些领域对象之间的协同合作关系，此时我们就可以用上GOF的几十种设计模式（足够应付大多数场景）了。

更为一般的设计方法

并不是所有的场景都能非常明确地表明有多少参与者，这通常由业务需求在初期不明确且实现时缺少设计导致的，且大多数重构都是在这种场景下开展的。

IPO，即Input-Process-Output，对应于软件系统中的输入、处理和输出。对于已经识别的重构场景，不妨先关注这三个点：

• 输入，这些输入有什么共同特点，是怎么被构建的呢？
• 处理，对输入做了什么处理呢？产生了多少个中间角色？一共有多少角色参与？这些角色又是怎么联系起来的呢？
• 输出，处理完成之后，软件系统输出了什么？系统其它模块对这个输出如何使用？

关注输入，可以提取到软件系统中关键的数据模型，针对其构建特点通常可以引入“构建型设计模式”；
关注处理和输出，可以更清晰地找到关键的参与角色，引入合理的“结构型模式”来规范这些角色之间的交互方式；如果能把这些角色的行为再进行组织和分析，通常“行为型模式”就可以被引入了。

什么是重构？

《重构》一书的推出，使得我们越来越关注所谓的代码坏味道，出现这些坏味道的根本原因就在于软件系统的抽象与设计不合理。如果只是识别了这些坏味道，把书中的手段一一应用，似乎很难让人信服这是一次完整的重构。所谓的“网红重构”，大抵如此吧。

总之，任何不关注改善设计和解读设计意图的重构都是鸡肋。

注：

• UML：Unified Modeling Language，一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。
• 领域对象：领域驱动设计的关键术语
• GOF设计模式：Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides合著的《Design Patterns: Elements of Reusable Object-Oriented Software》