其实一直对模式很关注的，也看了不少书，因为也有了一些编码的经验了，一直觉得模式就是别人都这么做的，而且这么做也有很多好处，就跟古人发现“转木取火”，然后又偶然的发现事物在加热之后会更加好吃一样，而这个活动在被推广之后就该被称为模式吧！总觉得是偶然的发现，但是看了几本书又结合自己所做的项目中的实践之后发现自己真的小看模式了，而模式出现也不是完全偶然的。所以终于想写点什么了！
就如Grady Booch所说Pattern是使用于设计SubSystem的方法论，当我们的工程中有利用设计模式去完成了完善的类库和功能，那么我们的开发过程效率也会相应得到提高。同时我们也可以因为具体的设计模式而优化我们系统的架构啊，试举一例，BusinessFacade层，我们引入了Facade pattern，这样可以简化我们调用，而不用接触底层API，而同时BusinessFacade层帮助我们实现验证和一些UI需要的简单计算的话，那么一个系统就可以在很短的时间将一个Web程序移植为一个Windows程序。
上例中的这个系统的架式不久可以得到了优化并且很明显有二个优点：第一结构清晰，程序的生命力由哪些因素决定？规范性、效率，还有呢，也许一些人忽略了它的结构，它更易读懂那么它也更容易升级维护了，否则不久它将面目全非；第二Extensible，如果改进了BusinessFacade层，那么不论Web程序还是Windows程序都可以得到升级；第二点又可以理解为程序更加Robust，当然这些都是概念。
言归正传，什么时候才能发挥模式的力量，我的观点是：带着自由的思想去运用模式的方法解决问题。如果不清醒的去啃一本本Design Pattern方面的书，那么结果会是一个个UML图和一些“简单”的代码，让我印象深刻的是看到一个师弟啃一本书，然后问我“都说这书好，为啥这书里都是些Println Hello world Car...，这里面的应用都太浅显啊，这么简单的例子为什么Inherit、Implements啊？这不是画蛇添足吗？”。无语，我只好回他一句这书我还没看懂呢，也许是你目前水平太高吧，我觉得你该看更高级的应用了，再见时我说“你大概走火入魔了，多写点代码再看吧”。不知他现在看懂了没，也许在毕业前的二手书市上他已经卖给别人了。因为对他来说模式是没有力量的。
说这个我碰到的故事原因有二：一、模式是好东西吗？那么为什么对初学者来说他不是好东西？真的很值得思考，因为当他写了很多代码并且有了一定的知识储备之后，他会发现他写的或者他看到的就是模式，当他研究过设计模式后他会发现原来这些个API都用到了哪些模式...，一切都变得有了秩序；二、学习模式不该拔苗助长，正如前面提到的那个师弟，也许他明天还在套模式，也许他自从那次鄙视模式后永远和模式告别了。
自由的追求模式，因为也许当你再见模式的时候，它才是友好的，而你才是有力量的。