设计模式不难，难得是使用设计模式

设计模式真的是很简单的，一般情况下，23个模式就够我们用了，如果不够，按照这23个模式里面的思想，自己根据实际情况找到解决办法也不是难事。但是，如何使自己有意识的去使用设计模式，如何发现何时可以使用设计模式。

从我开始写程序的时候，我就很关心如果将来要对这个程序变更，怎么能花费最小的代价。后来看了《精通设计模式》里有这样一句：找到并封装变化点。感觉很不错，确实应该这样，但我怎么才能找到变化点呢。很多时候，我们很难想到以后会发生什么变化。记得另一本书里也说过这就像是意料到意料之外的事情。是不是要对着设计一点点的找可能会发生变化的地方，然后再使劲想会发生什么样的变化，然后重构？

很多讲设计模式的书里在讲一个模式前一般都有一个例子，先说一个没有使用模式的设计，然后说，如果将来……，这个没有使用模式的设计会如何难以更改，然后讲解用模式后如何如何好。问题是：我如何能想到以后会发生哪些？

这个得看项目经验了，以前跟一些老鸟在一起工作得时候深有体会，他们因为多个项目得磨练，对于系统框架得可能变化点熟得很，比如分页框架，他们一般就是用适配器模式，以利于未来引入新得分页开源框架，还有就是对xml文件得处理，对于像我这样得新手来说，看到得是接口，具体内部用得是哪个开源框架，他们也做了封装。还有就是数据源和dao，一般都是用工厂模式，以方便在各个数据库间得切换。

另外就是，项目分不同区域得版本，主要框架是一致，但是在具体业务上却大有不同，具有地方特色，那么就需要对业务层进行高度抽象，灵活使用工厂模式，门面模式，策略模式等等，这样才好方便地方实施程序员进行扩展以及代码重用。

我刚开学习设计模式得时候，也是经常猜，猜未来得变化点再哪里，但是工作了以后，看了一些实际的项目代码，回过头来看那些开源代码，才领悟到设计模式是具体实践的升华，来源于实践，高于实践，并指导实践。

不要太过执着于使用哪种模式，而是抓住本质，为什么要使用模式？自然就知道该如何去做了。

[quote="calmness"]不要太过执着于使用哪种模式，而是抓住本质，为什么要使用模式？自然就知道该如何去做了。[/quote]

设计模式的本质无非就是解藕。这个大家都知道，关键的问题是什么时候，在哪里解藕。 很多人没有机会参与大型项目或者说没有机会与经验丰富的高手一起工作，比如我，虽然也做了不少东西，但都没有拿出来给别人用，不是不想，而是没机会，比如做了一个网店系统，虽然大部分的功能都有，但比起网上流行的免费系统还差得多，实在不好意思拿出来，也就不会发现自己项目中哪些地方是容易变化的。不是不懂设计模式，做东西时候想的最多的也是如何解耦，如何更好的适应变化，但是正如我开始说的，实在很难想的出如何才能哪些地方会发生变化。归根结底，还是实际项目经验不足。而且，事先想到哪些地方是容易变化的，确实有点困难，即使很熟练的设计者也只能应对已经经历过的场景，这些场景必定是曾经让设计者吃过亏的地方。难道非得以失败一次的代价来学习一个变化的场景？这个代价似乎也有点大。

这东西急不来的，得靠一两个项目得积累，而且本身要敢于重构，和创新学习，比如我刚开始工作的公司，系统框架是做得不错的，有一套比较方便的ui映射机制，只定义一个action类（用的是struts），下面的程序员只要实现一个dao业务类即可，但是后来我发现这个dao类于web层结合得太深了，其他人写到后来，都是直接在里面sql和http quest横飞，于是就尝试着在自己写得模块实现域编程，“好歹要写几个domain，一个纯dao类吧”这是我当时得想法，虽然 比起原来那种方法表面上耗费得时候要多（多几个java文件），但是代码清晰了，自己也得到提高了。再后来就是对一些设计模式得简单运用，当然前提是要保障项目进度。

举个例子说明一下我对设计模式的理解吧：

比如当你的程序需要一个算法时，而且这个算法可能有不同的实现，那么你就设计了一个接口，具体算法放在实现类中，然后在程序中调用这个接口。

那么，这个设计是怎么得到的呢？一种方法是想到了策略模式；另一种方法是通过软件设计的基本原则（松偶合、封装变化）和OO思想（继承、多态）得到如上的设计。

如果你是用第二种方法的话，那么应该说你能很好的运用策略模式了。

说到这里，想到了武侠小说中的一个词“高手无招”。设计模式相当于招式，软件设计和面向对象的基本思想相当于内功。当你在实际的设计中，能自如的运用内功，且得到的设计恰好与设计模式中的设计相吻合时，就说明你会使用设计模式了。:-)

其实，设计模式真的很简单，比如好多都是继承＋多态（或着说一个接口/抽象类加上几个实现类）就成为模式了（比如模版方法、策略模式等）。

同意,关键是如何能够在程序中应用....特别是在设计一个应用平台的时候,设计模式的应用可以增加平台的扩展性、稳定性、兼容性...

在学习设计模式时，我一直有一个疑问，具体的23个设计模式和诸如：封装变化、开－闭原则、面向接口编程这些设计原则那个对程序员更重要

模式：
就是对一些非常恶心的问题的
相对不太恶心的解决方式。
或者说对非常恶心问题的最经典的化简可能。

要是你看到某个代码会有恶心想吐的感觉。
或是对某种模式，
非常的不想这么做
但又找不出来什么更简单的方法的话。
那么恭喜你，你已经上了贼船了。

PS：抱着模式是写不出好的代码的。
如果你真的想学模式，
看经典的代码，
再看恶心的代码。
每种模式都会对就一个简单的但恶心的代码实例。
PS2:对模式的进行摩拜的人们问一个问题：如果不用写恶心的代码还要模式干什么？