模式总论-总诀式

在探讨模式的概念之前我们来看一个例子，独孤九剑共有九剑，独孤求败将不同兵器分门别类来研究破解之道，破剑式用来专门对付所有使剑的高手，破掌式专门对付使掌的高手，而破箭式专门对付各类暗器，当年令狐冲就是用破箭式救了他心爱的小师妹，以及整个华山派。这里的九剑就是九种模式，它们是独孤求败创建的，传给了风清扬，再传给令狐冲，说明模式是一种可传承、重用的一种经验。各种模式具有各自的价值，各自的出发点或动机也不一样，换句话说，不同的模式代表了不同的价值衡量标准，如破剑式的价值准则就是打败所有剑术高手。我们应用时就是靠这种价值准则来识别和选择模式的。

    认识模式并不难，但要给它下一个定义却很难，因为每个领域对它的理解不同，所以它是一种很高级的抽象，正如老子的那句话－道可道，非常道，名可名，非常名。模式也是如此，所以我们只要理解了模式的几个要素，模式的本质和价值观就可以了。

 

    模式有三大要素：问题，环境，解决方案。

    问题当然就是你要解决的问题，注意这里指的是一类问题，从一个具体问题中抽象出来的，如果只是一个问题，只发生一次，就无所谓模式了。就破剑式而言，对付所有的剑法是一类问题，而不仅仅是对付某一种剑法。

    环境指的是问题发生的环境，就是说面对一个有武功的人，他是使剑的还是使掌的得分辨出来，还有就是这人内力的是否高深，就是一个人的武功环境，了解了这个才能作出决策－用哪一剑对付他。

    解决方案自然就是解决问题的一种方法。也就是用破剑式来对付剑术高手。

 

    模式存在的基础：

    模式的存在的目的是因为它要被重用，如果遗失了这个本质，模式就会成为一种束之高阁的理论，模式是依存于具体实践的，是对具体领域具体问题解决方案的一种抽象。所以模式不是抽象的理论，而是可重用经验的总结，抽象。

    模式具有时效性，举个例子，我们都有过远行（旅行，出差，探亲）的经历，比如我们从北京到上海，你打算怎么走，有几种可选的模式：走路，坐马车，乘火车，乘飞机等。走路或坐马车也是一种模式，但那是一种废弃的模式，因为在古代我们没有发达的交通工具，只能如此，而现在科技发展了，它就不再适用了，这也正好验证了马克思的“真理是相对的，不是永恒的，任何存在的事物都会灭亡。”

    模式具有有限范围的适用性，认识这一点很重要，比如独孤九剑，有破剑式和破掌式，破剑式是针对剑类兵器的，而破掌式是针对类似金刚掌，如来掌等掌法类的。如果令狐冲拿着破掌式去对付东方不败，那早就死定了。再举个开发中的例子，GOF的设计模式中有一个Factory模式，它的好处主要是封装了一族类的实现(比如一种商品，他们有不同的型号，不同的价格，但他们的功能性一致，价格也是遵循某种算法的)，由factory决定你要创建的类，你可以在运行时动态地从文件里读取你要实例化的类的ID（比如这种商品的某种型号），然后用factory来实例化它，这种运行时的动态特性让你不必把代码写死－hardcode。而且对使用API的用户隐藏了具体实现细节的同时又获得了可扩展性，今后当你要添加新的型号的该种商品时你只需添加新的类而不需更改现有的任何类。听起来不错，但获取这种优点是有代价的，会引入复杂性，而且问题是你不是任何时候都需要这么有类似行为的一族类，如果你只有那么一个类就可以了，你当然没必要把事情搞得那么复杂。很显然这种需求是在factory模式的适用范围之外的。

            模式具有原子可操作性，为什么这么说，因为一个设计结构组合应用好几个模式，就是说各模式之间没有任何耦合也不存在排斥，他们可以共同分担责任来构造一个架构。比如GOF的设计模式中有一个Flyweight模式，它本身就是有Factory模式和Composite模式组合而成的。还有一个例子就是，我们用Command模式时就经常用Factory模式来产生Command的实例。这种例子还有很多，因此我们说模式是具有原子性的。

            模式是可以变异的，模式重要的是它的思想，而不是它的外在表现形式，所以一种模式可能会有很多种变体，我们在实践中用到的模式可能和教科书上的长的不一样，但只要它的思想是一致的，在概念上是一致的，那么你用的模式就是这种模式。比如说GOF的设计模式中有一个Singleton模式，我们都知道这个模式是用来保证一个类只会产生一个实例，但是你有可能遇到某个应用是需要只产生有限个(比如5个)实例，怎么办，很简单，你把有限个实例储存在一个HashMap里，今后只能有这几个实例就可以了。这显然还是Singleton的思想，在限制实例个数的概念性上和Singleton是一致的。

 

模式选择的价值观：

我们永远选择最适合我们需要的模式。选择用什么模式是要具体情况具体分析的，需求不同、技术环境不同会直接影响到模式的选择。在这个领域里，没有一成不变的规则。

下面举个例子来说明，我们要描述一个CD的特性，如果我们是在开发一个CD播放器的话，我们只在乎这种CD是VCD还是DVD格式，因为我们根据格式来播放，我们不管CD是什么内容。这时我们可以用一个Strategy模式来描述CD，我们可以定义出VCDStrategy和DVDStrategy两个策略类来区分不同格式的CD，因为他们只是解码算法不同，但播放行为应该是一致的，所以我们通过剥离算法来获得行为的一致性。而当我们要开发一个CD管理软件时，我们需要根据他的内容来分类，比如动作片、卡通片、情感片等，而其中动作片中，又按语言分成内地片、港台片、英文片三类，然后英文片又分成美国片、印度片等等，很显然我们关注它的层次结构，这当然是应用Composite模式的最好时机，我们把所有CD存储在一个Composite的层次结构中，今后可以很方便的查找、管理。

我们从这个例子可以看到，不同的应用需求我们采用了不同的模式。这说明了模式选择的价值准则就是，我选择的模式最适合解决我所关注的问题。关注的点不一样，选择就可能不一样。

另外我们也可以看到，模式没有绝对的优劣之分，每一种模式都只是在某类需求上体现它的价值。往往当你获得一种价值和优点的同时可能就意味着失去另一种价值和优点。比如你选择了Singleton模式，可以获得单一实例的优点，却失去了可继承的OO特性。又比如你采用MVC(Model-View-Control)架构模式时，将领域逻辑和界面可以很好的分离，但获得这种好处是以复杂性为代价的，会引入很多与你的领域逻辑无关的类。这也就是说每一种模式都只满足了一类价值准则。