设计模式，我想对于园子里的朋友来说已经是老生常谈了。特别是园子里象Bruce Zhang、TerryLee、吕震宇 等几位的作品，想必各位已经都拜读过了吧，本人也是，并且受益非浅。
但即使如此，我还是想在此谈谈自己对于设计模式的看法和见解，一来对自己学习设计模式的一个总结，二来也希望园子里的各位朋友能够指正错误，也使得自己少走些弯路。如果能够帮助到一些人，那是再最好不过了。
对于设计模式的定义，每本书都有它的写法，每个人都有个人的见解，在此引用李建忠老师教程上面的一句话“设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。”，确实，每一种设计模式都有其解决的特定问题，需求的变化，导致解决问题的变化，从而我们要用到的解决该问题的模式也将随之改变。也就是说，“变化”是使用设计模式的前提，如果软件设计一但编码完成就不再变化的话，那么设计模式也就没有必要在此讨论了，也没有其存在的必要了。可能有很多人在刚刚学习设计模式的时候会想，既然设计模式是解决某一类常见问题的，那么我们只要把每一种设计模式的使用代码背熟了，就可以使用了，我也一样这样想过，这也让我想起一篇文章，上面写着一个人去面试，他对面试官说，他曾经开发过一个软件，在这个软件中，他用到了GOF中提到的23种设计模式，结果他没能被录用。我想如果一个软件中要用到所有的23种设计模式的话，就应该要想到是否设计过渡过了（或许有些大型软件确实需要，这个我就不得而知了（:）。软件开发时，需求的变化是复杂的，也是不可预测的，如果我们记熟这些设计模式的用法，或许也可以照搬照抄的用到项目中，可一旦如果需求变化了，那么就无法应对。这是因为软件开发更是变幻莫测，目前还没有一种模式能够应付任何的变化，或者可以说，现在的这23种设计模式根本满足不了这些变化，在这种情况下，只有把这些设计模式的根本点理解透了，才可以活用，这需要经验的积累。
设计模式的基础是面向对象，离开面向对象也无从谈论设计模式。所以，在学习设计模式之前，我觉得首先要理解的是面向对象的三大机制，即“封闭”、“继承”、“多态”。也只有理解这些了，才能去更好的理解设计模式的精髓。当然，反过来，理解了设计模式，就能更好的运用面向对象原理。
当然，设计模式也有其一定的设计原则可遵循，下面就照抄一下书本的东西：
1、单一职责原则。
我们要把功能尽可能的细分，每一个类应该只负责一块内容或只执行一个任务。那么怎么样才算达到单一职责了呢，那就是当一个类仅有一个引起它变化的原因时。
2、开放封闭原则
我们应该要做到，尽量不要去修改原有的类，但却可以扩展现有的功能。
3、替换原则
子类必须能够替换它们的基类。
4、依赖倒置原则
这只归决于二句经典的老话：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应依赖于实现细节，实现细节应该依赖于抽象。
5、接口隔离原则
每一个接口都要有明确的定义，不应该强迫客户程序依赖于它们不用的方法。
可以说以上五点是设计中可以遵循的原则，当我们的程序实现了这些原则时，那么我们就已经使用了设计模式了。在听完李建忠老师的设计模式纵横谈系列课程时，个人认为最经典的，也是最能概括设计模式用法的话就是“哪里有变化，就封装哪里”。当然，我们必须得先知道，变化点在哪里，这就需要我们不断的去实践，去领悟了。
开头篇就讲到这里了，感觉全部都是些泛泛之谈，呵呵，经验有限，见谅了。在下面的几篇里，我会通过一个实际的例子来描述我所理解的几个设计模式。
注：本文参考了李建忠老师的讲座以及Bruce Zhang、TerryLee、吕震宇 等几位的关于设计模式的文章。在接下来的几篇文章里用到的例子，我也取自TerryLee 的文章《.NET设计模式（3）：抽象工厂模式（Abstract Factory）》中的虚拟案例，因为，我觉得这个案例对于我的理解来说能够很好的表达，也不用再费事去想一个案例，况且对于园子里的朋友来说能够更好的理解，希望TerryLee不会介意。（当然在涉及到别人版权的，我会标明）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。