先抛开上面这个实例的设计思路，这里面反映出一个问题：软件开发过程中，软件体系结构同样需要“重构”。

结合经典的《重构》，这里简单的写一下软件体系结构重构的定义，原因，设计，方法。仅作抛砖引玉，希望能和大家一起思考。

何谓重构

对软件体系结构的一种调整，目的是在不改变其“外在行为”的前提下，调整其结构，使其易于修改，维护和理解。

为何重构

1、使整个系统易于添加新的功能。为系统添加新功能将会非常的容易。

2、调整系统中各个模块的功能，角色，使整个系统更容易理解。
何时重构

由于系统结构的重构成本非常高，所以要选择一个合适的重构时机。

1、为系统添加功能时重构。此时项目进度压力如果非常大，这放弃此时重构。

2、软件第一个版本开发完毕后重构。在第一个版本开发完毕，第二个版本开发之前，根据第一个版本的开发经验，对系统进行重构。

3、开发出系统原型时进行重构。开发出一个系统的原型的时候，如果发现系统需要重构，这及时的进行，这个时候重构成本较低，但对是否重构决策要求较高。

重构的必要条件

重构之前必须为软件系统建立一个可靠的、自动化的功能测试环境，这样才能有效防止重构带来的危害。好的测试时重构的根本。重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验（selfchecking）能力。

重构与设计

系统架构层次的重构，因为重构的成本相对较高，所以预先设计的程度要相对较深，要尽量考虑系统可能遇到的情况，方案要适当的灵活和强固。尽量减少系统结构的重构。

软件体系结构的重和代码的重构的区别

1、针对的层次不同：一个是系统结构层次的，一个是代码层次的。

2、重构成本不同，系统结构的重构成本相对较高。

3、是否重构的决策者不同。

4、重构的时机不同。

1）这种理论为什么会提出来？
2）主要为了解决什么问题？
3）现有的理论无法解决此问题吗？
4）它是基于什么样的原理？
5）它是如何运行的？

2、学习了一段时间，拥有一定基础之后，要以一种批判的、怀疑的心态来对待学习的知识。当你拥有了对新知识的一定认识后，有可能会发现它很好解决了你以前遇到的一些非常棘手的问题，或者发现你找到了某一领域问题的完美的解决方案。这个时候，你要让自己坚信，“没有银弹”，没有包治百病的灵丹妙药。任何方案、理论、技术都有其依赖的条件，或者在解决原有问题后，引入的新的问题。此时，你要以一种批判的、怀疑的态度来对待它。要搞清楚：

1）它所依赖的前提条件是什么？
2）应用它的时候有没有什么假设？
3）它在那些场景下适用、那些场景下不适用？
4）它在解决原有问题之后，有没有引入新的问题？

3、当你达到专家级或顶级水平之后，应该持有一种“独孤求败”的心态：寻求新的挑战，争取“百尺竿头更进一步”，就像独孤求败一样，”闯荡江湖，只求一败 “：把每次的失败看成进步的机会。同时保持敬畏、谦虚的心态，你所掌握的知识，也不是”银弹“，也有其局限之处，或者随着环境的发展，已经无法适应环境，需要寻求新的突破。这个时候，你要根据你丰富的实践，提出创新的思路或知识。
总之：
1、在学习新知识、新领域的时候，要保持一个空杯的心态，只有这样才能为自己敞开自我提升之路。
2、偏见导致对新知识的排斥，教条倒是对新知识的盲从。
3、没有绝对的真理，也没有绝对的谬论。绝对的真理让我们盲从，绝对的谬论让我们偏见。