什么是设计模式?

　　什么是少林拳呢?少林拳是少林僧人经过长期的总结，得出的一套武功套路。有一本叫做少林拳法的武功秘籍，上面记载这这套拳法的适用人群，打法套路和学成后的效果。设计模式虽然记录在了设计模式一书上，但是要真正掌握设计模式光靠看每一个模式的结构并且进行模仿是不够的。试想一下，在真枪实战的情况下，谁会和你按照少林拳法，一二三四的套路打呢?打套路也只能用来看看，只有当你能根据不同的场景灵活出招的时候才能说是学会了这套拳法。相似的例子还有三十六计，这也是一种模式，每种计谋都是针对不同场景的，如果不管遇到什么时候都来个“走为上”，那这仗还怎么打呢?

　　总之，设计模式要用活才能发挥作用。

　　设计模式有什么用?

　　设计模式可以让你在遇到需求变化的时候不至于手忙脚乱。设计模式可以让你程序的可维护性、可扩展性更好。设计模式可以让程序的性能更高。当然，这些的前提是正确使用了设计模式，如果滥用的话那么设计模式可以让程序没人看得懂，让程序速度慢到死，让程序不能维护，添加新的功能等于重做。

　　设计模式的原则?

1. 　　单一职责：你不希望因为电脑内存损坏而更换CPU吧，同样也不应该让一个类有多种修改的理由。
2. 　　对扩展开放，对修改封闭：你一定不希望电脑只有一个内存槽，加内存就要换主板吧，程序也应该能在不修改原先程序的情况下就能扩展功能。
3. 　　里氏替换：如果你买的DX9显卡不支持DX9特性，那么这个显卡一定没法用。如果父类的方法在子类中没有实现那就晕了。在程序的世界中千万别认为鸟都会飞，先考虑清楚将会有哪些鸟吧。
4. 　　依赖倒置：针对接口编程，这样即使实现有变也不需要修改外部代码。其实，现在电脑的硬件、网络通讯等都是符合这个原则的，比如USB接口、PCI-E接口、TCP/IP协议。
5. 　　接口隔离：花3000买一个带拍照、听MP3功能的手机还是花1000买一个手机、1000买一个MP3、1000买一个数码相机呢?买了前者的话手机动不动就要修，而且还不一定是因为不能打电话而修，买了后面三样的话即使修也不影响其它使用，你说买哪个?

　　记得看过一个例子很恰当，说是修电脑比修收音机简单多了。电脑坏了，更换一个零件即可，原因是电脑中的各部分都是基于相对稳定的接口，而且部件各司其职，不会相互影响，电脑本身就是一个非常符合设计原则的产品。收音机的修理没有这么简单了，没有什么部件是插件式的，会修收音机的人肯定明白其中每一个部件的原理。

　　小程序就好像收音机，确实可以这么做，一共才一个人做的，即使重新做也用不了多少时间。几十个人的大项目如果要改一个需求需要牵涉所有人来修改，那么这个项目用不了多少时间就会因为维护成本太大，维护后BUG太多而报废。

　　怎样学习设计模式?

　　学习新概念英文要什么基础?首先，要知道26个字母吧。如果你对面向对象完全没有概念的话，建议先可以看一下面向对象的一些知识。毕竟，设计模式是面向对象编程模式的一种总结。学了26个字母你就可以学习新概念了，但是，为了能更好地学习最好是先学一下国际音标。对于设计模式的学习来说，你可以学习一下UML的一些知识。当然，完全不知道UML也可以学习设计模式，在学习的过程中慢慢也就会UML了。

　　设计模式不是什么很高深的东西，有了这些知识大胆地学习吧。很多人说，看了很多设计模式的文章，为什么就是看不懂呢?我觉得原因可能有两个，第一就是你没有花时间认真看，第二就是看的文章不适合作为切入点。不管学习什么，切入点非常重要，如果切入点不是那么平易近人的话很可能会把你拒之门外，对于初学者来说从实例切入最合适。最好是能碰到自己做过的项目的实例作为切入点，这样你一比较就知道为什么设计模式好了。

　　如果要把设计模式的学习境界分一下级的话，我这么分：

1. 　　第一重：能看懂设计模式的文章
2. 　　第二重：能自己写一个设计模式的骨架
3. 　　第三重：能自己编一个新的运用设计模式的例子
4. 　　第四重：能在写代码的时候想到似乎有设计模式适合，在翻阅资料后找到了这种设计模式
5. 　　第五重：在理解项目的需求后就能意识到哪里可以使用哪种设计模式进行优化
6. 　　第六重：完全掌握了设计模式的精髓，灵活使用各种设计模式以及其变种

　　不管怎么样，多看多做多替换才是学习的办法，别人举例十个都不及自己做一个例子，被动十个原则都不及自己体会出一个原则。每一种设计模式虽然都有一个骨架，但是也不必过于强调这个形式，很多时候根据自己的需求简化一点，改变一点，或者混杂一些其它的设计模式，只要能实现目的了，也是一个不错的选择。

　　很多人会觉得这么多种设计模式没有几种能用得上。我觉得这不是什么问题，用不上那就用不上，这些设计模式是大师经历无数大型项目后的精华，如果能在自己做的一个小项目中用上两三个就很不错了，用上二三十个的项目绝对是怪胎。用不上千万别强求，否则既不利于项目的可维护性又增加了工作量。

　　还有很多人会觉得这些设计模式很多都是相似的。而且每个人的感觉还不一样，有人觉得A和B很相似，有人却觉得A和B很好区分，但是B和C却很相似啊。感觉很好区分，说明你看准设计模式的着重点的，感觉一样说明你看到的还是它的形。双胞胎虽然形一样，但是神肯定不一样的，只要认准设计模式解决的问题，就不会看错。

　　关于本系列文章

　　本来这些内容都是用来进行公司内部每周知识分享活动的，既然有一些内容了，想想不妨就整理一下贴出来吧。也正由于这个原因，文章中的一些例子都基于团队内部成员所能理解的一些项目，可能这些项目对大家来说比较陌生，不过好处是例子相对比较贴近实际一点。本系列一共有20篇左右，除了介绍23种GOF设计模式中常用的一部分之外(一些设计模式的思想在C#语言中有了更简单的实现，一些设计模式不是很常用)还可能会介绍一些其它有用的设计模式。在这些文章中，我不会过多去说一些理论上的东西，也不会有结构图(这些内容网上到处都是)，所有的内容都是围绕相对实际例子展开。我想，只有这样才能更快的吸收设计模式的神而不是其形。在看文章的时候建议你结合《设计模式》一书以及博客园的其它设计模式相关文章一起看，这样才能对设计模式理解的全面和充分一点。

　　每一篇文章都会有以下部分：

1. 　　意图：抄设计模式一书的，因为意图实在是太重要，所以不得不首先列出。
2. 　　场景：以一个实际的场景来说明为什么要引入设计模式。
3. 　　示例代码：对引入设计模式后场景的说明。
4. 　　代码说明：说明设计模式中的几个角色以及代码中需要注意的地方。
5. 　　何时采用：从代码和应用两个角度说明何时采用这个模式。
6. 　　实现要点：实现这种模式必要的几个地方，或者说模式主要的特点在哪里。
7. 　　注意事项：模式的优点缺点以及什么时候不应该使用设计模式。