和许多人一样，第一次接触设计模式也是从《设计模式》开始的，在拜读完这本巨著后，在感到深深的震憾之余，还有一种将这本书推荐给公司里每个家伙阅读的强烈冲动。可是几个颇有面向对象编程能力的家伙却告诉我，这本书太深奥、太抽象了，看得叫人感到头昏眼花、云里雾里。
那时，我除了郁闷还有纳闷，郁闷的是这么伟大的书，这些家伙却一致反映很难看懂，看不懂，还如何从中吸取丰富的营养，迅速提高软件设计水平，从而提高产品质量？纳闷的是为什么这些家伙会一致反映看不懂，而我自己却没有这样的感觉呢？后来通过和这群家伙交流我才知道，他们不像我那样拥有丰富的程序设计经验，经历过的东西太多(我先自吹自擂一番)，因此在阅读这本书时，从自己过去众多的设计中挑选出相似的案例来进行对比，而他们却很难有这么多的案例去拟合每个设计模式，没有“实物”做参照物，阅读、理解自然是一个痛苦而漫长的过程。如果我想帮助这群家伙的话，只有“翻译”这本书，如何“翻译”？用常见的实例，用程序员的“语言”来解释设计模式，而不再使用原著中抽象的。
从那里开始呢？首先从回答两个问题说起吧。
第一个是学习设计模式最好从那个设计模式开始？
第二个是我最喜欢那个设计模式？
我认为回答第一个问题可以反映出回答者的“心态”，而回答第二个问题则反映出回答者的“心境．我的答案是，学习设计模式最好从“适配器”开始，我最喜欢的设计模式是“策略”。先说反映心态的“适配器”，程序员在成长过程中都有这样的极其相似经历：在别人写的代码基础上继续，比如完善或者维护别人写的程序。通常你我做的其实大同小异，先会去阅读已经写好的代码，感觉差不多了，下步动作是什么？60%的人不是开始“继续的”工作，而是开始改写、甚至是重写代码，还有40%的人是在“继续工作”，完成新东西的设计后，回头再来改写、甚至是重写代码。我敢打赌，只有不到10%的人会在别人的基础上“继续”工作。改写、重写的理由是什么，无非是别人写的太土、太臭，不改写、重写，心里不舒服，更“好”的理由是，和我“继续”的思路不同，比如接口不兼容，我写不下去，因此只有改写，改的太多，我又比较能干，因此干脆重写！
其实……其实……下一个在你工作基础上继续工作的家伙，和你的想法一样，你一样土，一样臭，他一样比你高明，一样会改写、重写你引以为自豪的代码。唉，就因为是软件，你我可以拿到源代码，因此你我手才会痒，才会有改写、重写的奇怪念头，想想硬件，自己没那个本事，也没有那个条件去重新设计、制造另一个主板，来实现一个满足自己需要的接口。每次开发一个接口卡的时候，你我还不是老老实实按“规范”去设计接口，再按自己的需要做个“适配”处理？！同样你有改写API的冲动吗，老实说我经常有，我特别讨厌win32API的许多接口，罗嗦不说，还无法提供我想要的全部功能，麻烦死了。但我改不了，因为没有本事改，也无法改。老实说，那些宣称喜欢linux的家伙，肯定有一堆想“改进”linux内核的自负家伙，我就遇到好多好多。那么改写、重写的效果如何呢，老实说，我自己有很深的体会，步入管理岗位后体会更深，客气点“条条道路通罗马”吧，心情不佳的时候“50步笑100步”吧，还不说时间(你总不至于聪明到1秒钟内修改完成吧)、成本(你改写、重写、测试的那段时间，你不会给老板说你不要工资吧)了。如果你心平气和去对比，你会发现我说的绝对一点不夸张、过分。
说了这么一大堆，就是想说，如果你想提高自己的工作效率，你想做更有意义的事情，你不想重复去造一个别人已经造好的轮子的话，下次遇到在别人工作基础上“继续”这样的“美差”的时候，首先要想到“适配器”设计模式，适配器设计模式太简单了，简单到我认为不需要说什么了，其实你能否有机会使用适配器模式，主要是看你的心态，我相信你一定能掌握他，不就是匹配个接口嘛。