设计模式背后的思想

设计模式背后的思想

前面写了一篇文章简单介绍了23个具体的GOF设计模式。通过那篇文章，大家可以达到“知”的层次，但是“知”不是最终目的。学以致用，才是我们所追求的。所以在学习每个具体设计模式之前，需要了解设计模式背后的思想，这样才能得到它的精髓，而不是流于表面，不然就有可能陷于“形式主义”的泥沼之中。

设计模式的目的

使用和学习设计模式一定要知道它为什么存在。最近电视里在放《精忠岳飞》，里面有一段岳飞和宗帅讨论阵法的对话。宗帅对阵法很是推崇，说要好好学习、仔细钻研。而岳飞对阵法不屑一顾，为什么呢？因为学习阵法不外乎是为了打胜仗，打胜仗有很多方法，阵法只是其中一罢了，如果有其他更好的对策，才不管什么阵法呢。宗帅就是陷于了为了学些阵法而学习阵法的陷阱里。

那设计模式是为了什么呢？最终目的肯定是为了开发出软件。软件开发是一个复杂的过程，涉及需求收集、架构设计、详细设计、编码实现、测试、部署等等各阶段。那设计模式在哪体现呢？我们都知道设计模式的对象是类和对象，已经很具体了，所以它更体现在详细设计和编码实现里面，这就是设计模式所在的位置。所以，不要妄想学习完设计模式就很了不起，如果这样想，就是不知天高地厚。知道了天高，才知道自己和天的差距，知道自己前进的方向。

设计模式给详细设计和编码实现带来了什么呢？复用！打比方来说，如果大家都是修路的，凭什么你就比别人修的好呢，答曰：“用的料少，并且以后再修，动作小”，这样就对了。这已经是所有工程项目都需要考虑的问题，如果你还是个码农的话，赶快学学设计模式，加入“工程师”的行列吧。

复用的探究

既然设计模式的目的是为了复用，我们需要认识一下它。大家在日常生活里也会碰到一些复用的例子，比如：垃圾回收、废物利用等。我把复用分成两大类：

1，  从空间上分：“你”用，“我”也可以用。比如说公司里，几个部门共用一个会议室；回到家，几个人共享一个WIFI；去颐和园，大家可以租脚踏船在昆明湖里游玩等等。

2，  从时间上分，就是可以用多次。这个例子就很多，比如手机、电脑就可以使用多次；纸巾什么的使用一次，脏了就不能再用了。

我们先来看看1，“你”用，“我”也用涉及三方：“你”、“我”、被复用方。“我”是否能用上，这要看被复用方是否接受，就像谈恋爱一样，你喜欢没用，还要她喜欢你，所谓“一个巴掌拍不响”。所以针对被复用方是否接受分出两种情况：

1)        被复用方接受“我”：这种情况对于“我”来说，很好，不需要做什么事情，但是对被复用方来说就有很高的要求。在设计模式中很少见，谁没事同时支持多个接口阿！

2)        被复用方不接受“我”：这个时候“我”该怎么办呢？装成“你”，哈哈，不是说“你”用，“我”也用嘛。既然“你”可以用，那么“我”装成“你”，这样被复用方把“我”看成了“你”就OK拉。但是怎么装扮呢？继承和组合。只不过继承是静态的，“我”如果要装成“你”，需要“我”有先天条件，长得本来就像“你”；而组合才不管这些，只要我愿意，不管长什么样，都可以。从这点来说，组合优于继承。

现在，再来看看2。使用多次可以分成三种：

1)        使用后，被回收作其他用。这种情况，在生活中很多，在设计模式中很少。

2)        情况不变，使用多次。在软件的世界里，对象不像生活中的消耗品，一般都可以重复使用，只要不销亡。不过需要注意的是，使用后，对象的状态可能会改变，再次使用的时候需要重置。

3)        情况变化，仍可使用。这个是设计模式中考虑最多，我们主要说这个。

情况变化在软件的世界太过普遍，因为软件是为需求而生，需求变化一方面可能是因为前期没有沟通好或者没有足够深入的挖掘，另一方面也因为社会的发展变化。比如说以前的手机很弱，界面是平面就OK了，但是现在手机的CPU、GPU都很不错，有追赶PC的势头，可能就需要3D界面了。为了应对这些变化，主要有两个办法：

1， 和变化隔离

2， 如果隔离不了，要把变化缩小到最小的范围。

一般公司的网络为了安全，和外部网络是隔离的，主要有两种方法，物理隔离和逻辑隔离。简单来说就是直接断开和间接断开（没有断开，只是中间加了防火墙）。和变化隔离一样也有两种方法，这两种方法和网络隔离差不多。我这里为什么要把网络隔离提出来，目的就是告诉大家，其实很多东西都是相通的，不管从事什么工作，做好了，都了不起。这个做好了，其他工作也能做好，反之，这个做不好，其他的未必做得好。闲话不说，我们来看看和变化隔离的办法：

1)        完全隔离，找替代。替代可能来自内部，也有可能是中介，中介是最常用替代方式。学过Spring的知道，里面的依赖注入也是完全隔离的一个好方法，它提供了一个容器，用来管理对象的生成，并且定义了一定的语法来表明各自的依赖，容器会根据这些依赖说明来适时注入。用设计模式的原则来归纳的话，就是迪米特法则：尽量不要与其他类互相作用,减少类之间的耦合度。

2)        使用抽象接口相连。这个抽象接口，就相当于逻辑隔离里面的防火墙，一切通信都要通过这个接口，接口之外的数据都被忽略。用设计模式的原则来归纳的话，就是接口隔离原则：接口来规范类,用接口来约束类。

接下来，我们来看看怎么把变化缩小到最小的范围：

1)        减少变化。前面不是说变化总是有的么，这里怎么又说减少变化呢。前面说的是需求变化，需求变化的确不可避免，但是在设计的时候如果考虑到可能变得地方，让变得地方可扩展，其他的地方就会固定不变。换句话说，就是实现需要依赖抽象，因为抽象一般是不变的，而实现千变万化。用设计模式的原则来归纳的话，就是依赖倒置原则：高层模块不应该依赖底层模块，抽象不应该依赖细节，细节应该依赖抽象。

2)        有专人负责变化。有专人负责，这个变化就是这个人的，影响范围就会局限于这个人。用设计模式的原则来归纳的话，就是单一职责原则：就一个类而言，应该仅有一个引起他变化的原因。

3)        力争少向外沟通，实在要沟通的话，固定对外交涉人。比如说一个公司如果没有专门的外涉人员，一方面没有一致的口径，另一方面每个人都可能受到干扰。

好了,今天就先到这了,有时间的话,再写写设计模式是怎么运用这些思想的。