熟悉设计模式和重构的人一定对Refactor To Pattern或者RTP一书不陌生。重构到模式也成为了业界比较流行和推崇的一种做法。结合本人学习、使用设计模式的经验，总结了下自己这方面的历程，感觉用“RTP三步曲”介绍比较合适。

 

1 Rush To Pattern 急于使用模式

     刚刚接触设计模式那会就知道这是出于大师之手，一定很好。在工作中感觉可以用就迫不及待地使用，没有条件使用也要创造条件。在设计中没有看到一些设计模式就感觉缺点什么，于是乎就臆想各种可能的变化，然后引入各种模式来提高柔韧性以对应这些变化。最后设计变得无比笨重、臃肿，应用的设计模式在一起也是一个大杂烩，根本无法融合。那种心情和一个习武之人刚学会一些招式，没地方施展，手头痒痒的感觉差不多。

 

2 Refactor To Pattern重构到模式

    经历了Rush To Pattern这一阶段后，一般使用模式会变得相对保守，从而开始被迫使用一些模式来解决已有的问题。其中一种有效的手段就是大家熟知的Refactor To Pattern。工作中会不断发现一些设计和代码中的坏味道，通过引入合适的设计模式对应，从而实现设计的改善。这时对设计模式的需求也相对比较真实和成熟。

 

3 Reason To Pattern推理到模式 
     不过重构是有代价的，重构需要一个鼓励重构的公司文化和自动化测试等重构的安全网。因此一个成熟的软件设计者应该在初期就具备一定的扩展性以对应不断变化的需求。对设计模式掌握到一定阶段以后就可以使得一部分比较确定的设计一步到位，从而避免了大量重构的风险。重构主张任何已经实现的设计和代码都是有价值的，无论多么糟糕经过重构后都可以变得优雅。但这并不意味着重构鼓励前期糟糕的设计和代码。重构只不过是一个偿还技术债务的过程，而且这些债务只要软件存在迟早都要还的。对设计模式的理解慢慢成熟之后，也可以凭借相关理论和经验让设计模式自然地融入到最初设计中。

 

以上。