作为本系列文章的第一篇，笔者在此想表达一下个人对于设计模式的一些理解。因此笔者自问自答几个问题。1，什么是设计模式？2，在软件高速迭代的今天，设计模式是否重要？3，四人帮提出了23个设计模式，是不是设计问题无出其右？4，设计模式和语言是什么关系？5，设计模式和面向对象的关系？

1，什么是设计模式？

      拿百度谷歌一下，能够找到各种各样的回答，仅仅是非常多的回答实在是会让人找不到北，模式这个词确实非常高大上。因此经常出没于学术界。

针对设计模式这个问题。笔者对设计模式的理解是。设计模式能够觉得是解决某一类问题的通用方案。为什么是通用的呢，事实上GOF没有创造不论什么新的设计方法。相反他们是将前人的软件设计方法进行了充分的归类总结。得到了最著名的23条设计模式，因此能够说这些设计模式在有一个响当当的名字之前已经有非常多的人在使用。

2。在软件高速迭代的今天，设计模式是否重要？

      重要与否，在于使用者对其的态度，设计问题本来就没有一个充分必要条件，而且在一个高速迭代的开发周期内，结果也许比过程更重要，毕竟玩家，策划不care你的架构是否优美，结构是否灵活可扩展。可是从一个软件设计者（这title不错。请不要叫我程序猿）的角度而言。你可能须要一定的美感（攻城狮也是有追求滴），当然，最重要的是你须要架构具有足够的可扩展性（非常飘渺的一个词就像高内聚低耦合一样，仅仅可意会不可言传）。可扩展和藕合可谓是一对天敌。假设你不介意藕合性。设计模式可能是没有什么意义的。否则那你真真须要去找找四人帮了。

3，四人帮提出了23个设计模式，是不是设计问题无出其右？

     这样的问题的答案肯定是否定的，高考选择题的诀窍啊，GOF毕竟历史比較久远了，GOF的23种模式是经典。可是随着软件的发展，也出现了非常多新的设计模式。

比方，2007年google发表了一篇震惊我们攻城界的文章。提出了Map-Reduce模式。有人觉得这是个算法，也有人觉得这是个设计模式，whatever，MR确实真真推动了行业的发展。那么C/S。B/S，MVC，MVP是不是设计模式呢。应该是吧。笔者个人觉得（也能够觉得是体系结构）。

4，设计模式和语言以及面向对象是什么关系？

     这之间好像没有半毛钱的关系，之所以全部关于设计模式的书籍都是用Java语言来解释的。是由于Java语言面向对象的特性非常easy表述设计模式要解决的问题。而且Java的语法和C/C++相似。让绝大部分人都能非常easy理解，面向对象的Java语言非常easy表述设计模式要解决的问题，事实上这里也隐含了一种意思，面向对象的语言更easy使用设计模式的方法来解决这个问题。设计模式本身讲究的是对问题的抽象，而面向对象也是为了对问题的抽象。试想假设使用C语言来解释设计模式，单就是函数指针的定义预计就会吓跑了无数的阅读者。

以下来分析本文要讨论的一个设计模式：观察者模式。

观察者模式，又称公布-订阅者模式。是GOF提出的23种设计模式之中的一个。属于行为型模式的一种，用于解决不同模块之间的通信问题。

观察者模式中的角色有2个：

      （1）主题（Subject)：能够理解为消息（及必布者）。

      （2）观察者（Observer)：消息的接受者（消费者）。

在一个标准的观察者模式中。主题和观察者之间的相互依赖是抽象的，因此他们之间的关系能够使用例如以下UML类图来进行表示

从图中能够看出当一个主题能够同一时候拥有多个观察者，当主题发生变化是通知全部的观察者。该模式解决这样一类问题：当模块B依赖模块A的数据时，模块B须要知道模块A的数据发生改变。而且使用抽象（DIP）的机制使得的模块间的耦合性大大减少。当不使用观察者模式时，模块B须要自己去定时检測模块A的数据是否发生变化，如此不仅添加了代码的复杂度，模块之间的耦合性也会变得更加复杂。

上面简要介绍了观察者模式的基本原理，由于网上有对其很充分的解说，故而此处不做过多分析，以下我们来看一下在游戏中怎样大量使用该模式来将解耦模块之间的关系。考虑一个游戏中的战斗单位，且称之为Boss，Boss有一个很重要的信息血量（HP）。在一场Boss战中会有多个模块依赖于该Boss的血量变化：

（1） UI模块：Boss的血条须要实时显示当前剩余的血量。

（2） Boss技能：当血量降低到一定值时会触发对应的技能（大招，召唤小怪等）。

（3） AI模块：当对方的Boss血量达到某个值时。能够触发某类AI。

（4） 很多其它的模块可能会依赖于HP值。

如此多的模块依赖于HP值的变化，因此须要十分慎重的处理模块间的依赖关系，否则极要可能使得模块间的耦合性异常复杂（当然。假设系统不复杂耦合不会是什么大问题），那么在真实的项目中是怎样处理这样的依赖关系的呢？ 观察者模式，可是我们不是使用标准的观察者模式，是观察者模式的一个变种，例如以下图所看到的：

当中的Handler是指我们定义的python函数（类函数），Boss是我们Member类的一个实例对象，Handler能够是技能模块，AI模块，UI模块等随意模块的函数，仅仅要其函数定义符合 def function(event)格式就可以（由于python是脚本语言，因此也是某种意义的抽象），当中evntKey是该函数监听该对象身上的事件，如对于HP变化的监听，我们定义为M_HP。当Member的HP发生改变是。主动调用dispatchEvent，全部注冊了M_HP的接口都会被回调。

事实上观察者模式是很简单的一种模式，同一时候也是很经常使用的模式之中的一个，该模式适用于解决1对N单向消息传递类型的问题，上面HP的样例。我们使用该模式很easy地攻克了不同模块间的耦合问题，当然我们并未完毕遵循标准观察者模式的体系结构，简单的变形。反而更利于详细问题的解决。