设计模式之前提--设计模式思想
我一直都只是个看客，很少发言，偶然加入西西的群，被感染的童心大起，所以就想写点什么，一看设计模式大家讨论的是相当地热闹，再加上自己几年来的设计摸索，一时童心大发就想说两句。
其实网上这方面的文章很多，看到很多人的回复，尤其是争论，最后发展到人生攻击，让我愈发意识到：对设计模式的思想应该先有个正确的认识，然后才可以很好的去交流设计模式。
设计模式思想是什么：
设计模式可以理解成一种经验，是大家在重复处理某些同类型问题的时候，总结出来的一些“经验”，采用这些经验可以大幅提高代码的复用性和扩展性以及维护性(当然还有很多其他特性)，可惜这些东西是“经验”，或者说是一种思想，思想类的东西不太容易表现和传承，所以人们开始总结，开始想办法图形化和量化，让其他人可以理解、可以学习。这就是现在的二十多种设计模式。问题是将思想量化出来以后，往往会产生很多的歧义，这就是争论的开端。
所以我们今天看到这十多种设计模式的时候，一定要首先明白它根本要表达的是一种“思想”！！不是一堆类图！且勿生搬硬套类图，以为完全符合某种类图的样子就是某种设计模式，那将会完全走入设计的牛角尖！
可能我说的这些很多人半信半疑，或者感觉对，但觉得我的话很虚，所以我想举一个例子来说明一下。当然肯定也有高人觉得这简直就用不着说，就像1+1=2一样的基础，但是我还是想写出来，呵呵。
示例：
我们看一个很容易理解的模式：策略模式，如下图，我们针对一个东西Context，可能有很多种算法ConcreteStarategyA、ConcreteStarategyB、ConcreteStarategyC，策略模式中抽象出策略类Strategy，策略类只管不同的算法，不去管什么时候该用什么算法，而是由Context自己去决定实际用哪一个算法。
好，现在我们开始想如果不用策略模式，策略Strategy实际上是Context内部的属性或方法，Context到需要用ConcreteStarategyA的时候就写ConcreteStarategyA的逻辑，需要ConcreteStarategyB的时候就写ConcreteStarategyB的逻辑，现在我们发现Strategy是多变的，可能很快就冒出个ConcreteStarategyC来，所以我们将Strategy单独提取出来，将Context和Strategy解耦，让Context自身和Strategy自身单独演变，这么说着说着你是不是马上想到这个做法多么像是桥接模式（Bridge Pattern）啊？(如下图)
不知道大家明白我说的意思了没有？就是同样画下面一个图，你根本无法知道他到底是策略还是桥接模式? 但是他们的思想（提取多变内容，然后抽象）是完全相同的，同一个问题，你从两种不同的地方入手，其实最终达到了相同的结果，异曲同工！所以有人说这是桥接模式的应用，有人骂这哪是在讲桥接，这明明就是策略模式，不懂还在这里误倒人。其实他们都没有错，只是出发点的不同。
综上所述，策略是一种思想，你要完全明白它要解决的到底是什么问题，然后才能被你所用。切勿死读类图，看到别人的实例，不要一开始就否认，看看他的解决方案是否用到了这个模式的思想精髓。当然新手也不要怕这么多种设计模式我怎么能记得住？其实别看这么多种设计模式，思想归根结低就一句话：针对抽象编程!
BTW：我看TerryLee的设计模式系列写的很好，可惜没有写完，另外发现像命令模式（Command Pattern）等后面的回复留有很多的疑意，所以我想有空就从这些方面入手，补充些方便大家理解的东西了。
下一篇：命令模式