难道“重构”也需要设计吗?

当然需要设计，只是不需要用什么uml tool会绘画那种class diagram。这种“正式”的设计只是用于存档，便于后人理解;有时候也用于与别人讨论的场合，标准的class diagram还是比较容易被大多数人接受。

但如果仅仅只是自己重构使用，那么在脑海中构思简单一把，或者在纸上简单画画即可了。

下面，把针对ApplicationManager的重构设计，绘制成一张思维图，姑且做个例子看看。(事实上，自己在重构的时候，仅仅只是在纸上简单画了画)。

这样，这个命令行类的最基本几个元素就被你抽象出来了：Option、TaskOptions、Task。

开始重构了：先别忙着就自己写，看看有没有现成的组件可利用?

写道这里，估计会有一帮人抱怨了：为啥不在最初的时候找开源组件呢?

如果直接找开源的组件，就谈不上什么“修炼”了，况且，现有的开源组件不一定适合自己。

但是，当你想清楚自己想干什么了，大概怎么干的时候，再去寻找“现有的组件”，收获会更多：

(1) 如果有类似的开源组件，你就可以更加全面的衡量了，而且比较容易理解开源组件的设计思路；

(2) 如果没有类似的，那你就开始重构吧！

有关命令行解析的开源组件，比较著名的就是Apache的CLI组件，目前release version是1.1。分析了一下CLI的设计，并画了张思路图，如下所示(注意，只涵盖了一部分主要的关系，其他辅助的没有涵盖，比如HelpFormatter等等之类)：

分析完CLI，你就会明白，这个其实并不适合我们的命令行类：

(1)CLI仅仅只是用于解析命令行的参数。

(2)CLI没有TaskOption这个概念，其所有的Option都是平等的。

(3)因为Cli只关注于命令行的解析，所以对于Option的解析做很复杂。但是这样复杂的解析方式并不适合我们的命令行操作，我喜欢解析较为简单一些，比如不需要OptionGroup这个东西。

(4)我们的命令行类需要完成：参数解析和任务执行，而不仅仅是解析。

但是，CLI还是有些地方值得我借鉴和吸纳的：

Options这个对象给了我灵感，而这正是TaskOptions所缺少的：TaskOptions可以利用Options对象去管理Option。

重构的过程：乐趣中不断改进

重构的过程是比较有乐趣的，当然，也是一种享受。

重构本身就应该是一个“迭代”的过程，一步步朝着目标结构逼近。

但是，重构过程中，会不断有些“细小”的改进。不要奢望过度的改变“你的原始想法”。如果你在重构过程中，发现你与原始的设计背离太远，那么建议你最好停下手头的coding，花点时间整理一下思绪，把整体设计再考虑考虑。

但是，细小的改进几乎是不可避免的。

举个例子：在最初实现Option对象的时候，我仅仅考虑了几个属性：名称、是否带有值，值、描述，是否必须存在。但是在后续实现打印Usage的功能的时候，却面临了一个问题：输出的option帮助信息总是无序的，当然，我试图通过option的名称来排序，但是这似乎并不是一个“业务化”的排序。最后，我不得不为Option增加了一个“order”属性来允许客户手工设置哪些参数的输出顺序。

这样改进的例子在重构过程中还很多，因为比较琐碎，具体就不再这里叙述了。事实上，这些只需要经历过几次重构过程，就会在这个“旅途”中经历不少几次的代码改进。

重构的过程：不断的TestCase验证

这是一个老话题了，重构的过程，就伴随着不断TestCase验证的过程。不断的TestCase才能保证你的实现是在“正确”的方向上。“迭代”与“TestCase”总是相互依存的。

重构，究竟修炼了什么呢?

一次重构，到底让自己修炼了什么呢?

仅仅只是让一个组件的结构更优良了吗?哦！这只是看的见的收获，还有很多你自己都看不见，却可以感受到的收获。

(1)重构的过程，就是让自己的先前的构思设计更加趋于完善的过程。当某一次重构完成以后，你自己的“设计能力”必然会有所提高，当然，这种提高短时间并不可能带来“质的飞跃”，但是，随着时间的积累，“重构”修炼次数增加，设计的组件越来越复杂，那么总会有一天，你可以轻松把握一个复杂组件或者产品的时候。

(2)不要因为读了本《设计模式》就认为掌握了“优良的类关系设计”。书本只是介绍了别人的经验，但是是否能够真正的吸收，则是需要在“重构”中一次次“尝试”和“积累”的。毕竟“重构”是连接旧有代码结构和新代码结构的桥梁，这个过程的演进，其实就是在一步步实践各种“模式应用”的过程。

(3)还记得那本《分析模式》吗?它其实在给大家阐述一些“场景的实现模式”，你认为这些模式是怎么出来的呢?——其实，这就是那些大师们在不断的积累、演进、重构中的经验总结。——比如我们刚刚重构的这个命令行类，它其实就是一种场景的实现。

当然，在“重构”过程中，你也会偶尔经历一些“代码技巧”方面的尝试，让你的代码更加简洁、高效、结构优良。——这也会修炼的代码功底。

以上仅仅只是笔者的一些心得。我想，面对重构，还是读者自己的实践，更能给你自己带来更多的收获。