设计模式是什么鬼（终章）

设计模式就是以语言特性（面向对象三大特性）为硬件基础，再加持六大设计原则的灵魂组合而，总结出的一系列套路，本章要讲地就是灵魂。

单一职责
我们知道功能完备的软件系统是复杂的，系统的拆分与模块化是不可或缺的，而面向对象是以类来划分模块边界的，也就是说每个类都代表着一个功能角色模块，其职责应该是单一的，不是自己分内的事不应该负责，这就是单一职责原则。

举个例子，灯泡一定是可以亮和灭的，我们定义一个灯泡类并且包含“功率属性”以及“通电”和“断电”两个功能方法，这便是对灯泡的封装，一对大括 “{}”定义了其类模块的边界。

虽然说我的领域我做主，但绝不可肆意妄为。比如现在客户要求这个灯泡可以闪烁的霓虹灯效果，我们该怎样实现在电灯类里再封装一堆逻辑电路控制其闪烁，比如新加一个flash()方法，并不停来回调用通电断电然是错误的，灯泡就是灯泡，它只能亮和灭，能不能闪烁不是灯泡的职责，既然进行分类，就不要不伦不类。所以我们需要把闪烁控制电路独立出来，它们之间的通信应该通过接口去调用，划清界限，各司其职，这才是类封装的意义。

在访问者模式中对资源模块的访问就是非常典型的应用，我们对资源内部并没有进行逻辑修改，不应该为了附加的功能而修改资源，而是新建访问者模块中去实现这些附加功能，今后对系统扩展时我们只需添加新的资源类与访问者类实现即可，系统模式一旦完美确立就不再修改现有代码，这就是对扩展的开放，对修改的关闭，添加加比修改好；反之假如系统升级要牵扯进来大量的代码修改则说明这个设计是失败的，是违反开闭原则的。其实开闭原则的例子不胜枚举，对抽象的大量运用奠定了系统的可复用性、可扩展性的基石，增加了系统的稳定性，读者还需要自己揣摩、体会。

里氏替换

假设我们定义有这么一个类“禽类”，给它加一个飞翔方法fly()，于是客户端可以自由自在地调用其飞翔方法。不巧某天需要鸵鸟加入禽类的行列，可惜地是鸵鸟并不会飞，这下就闹得整个鸡飞狗跳，此时客户端就不能调用禽类的飞翔方法了，因为这个禽类有可能就是鸵鸟，这就违反了里氏替换原则。我们意识到最初的设计一定是有问题的，因为不是所有“禽类”都会“飞”，所以对于禽类不该有飞翔方法。

接口隔离原则要求我们对接口尽可能地细粒度化，小接口总比大接口要好。比如我们都知道Runnable接口，它只要求实现类完成run方法即可，不会把不相干的行为也给加进来，所以它只是定义至其力所能及的范围，点到为止。其实接口隔离原则与单一职责原则如出一辙，只不过是对高层行为能力的细粒度化规范，这非常好理解，分开的容易合起来，但合起来的就不好分开了，请记住，分开容易合起来难。接口隔离原则能很好地避免接口被设计地过于臃肿，轻量化接口更不会造成对实现类的污染，使系统模块间依赖变得更加松散、灵活。

依赖倒置

依赖倒置是指出只依赖抽象而不依赖具体实现，从而达到降低客户端对其他模块耦合的目的。我们知道客户端类要访问另一个类，传统做法是直接访问其方法，这就导致对实现类的强耦合，而依赖倒置的做法是反其道而行，间接地访问实现类的高层抽象，依赖高层比依赖底层实现要灵活得多，这也印证了我们在里氏替换里提到的”针对抽象编程“。

举个例子，公司CEO制定新一年的策略及目标，为提高产出效率决定年底要上线一套全新的OA办公自动化软件。那么CEO作为客户端要怎么实施这个计划基层程序员们并调用他们的研发方法吗世界上没有以这种方式管理公司的CEO吧，作为高层领导一定是调用高层抽象，大手一挥调用IT部门接口的work方法并传入目标即可。至于这个work方法的实现是公司程序员去研发写代码实现，或是找外包公司项目承包，甚至是直接找成熟的产品直接购买，CEO完全不必操心，这时就达到了与具体实现类解耦的目的，不合适还可以随意灵活替换，这就是把“依赖底层”倒置为“依赖高层”的好处。

此外还有像中介模式、适配器模式等等都好像是给陌生人搭桥一样的松耦合典范。系统模块应该隐藏内部机制，大门一定要紧锁，防止陌生人随意访问，而对外只暴露适度地接口，这样才能保证模块间的最少知识通信，切勿越级汇 ，禁止跨界、干涉他人内务，让模块间调用变得”傻瓜化“，即开即用，使模块间降低耦合性，提高软件系统的可维护性、可扩展性。

常道

软件设计绝不能不切实际而刻板生硬地套用模式，其实有时并不适用，也许本来几个类就可以解决的的需求非要拆成几十个角色类，结果适得其反，很简单的一个系统搞得臃肿不堪，生搬硬套的设计模式反倒变成一种鸡肋。其实各设计模式之间都是有共通之处的，有些看起来十分类似但又能解决不同的问题，套路当然有类似之处了，即便作为灵魂的设计原则也隐隐约约有着千丝万缕的关联，其实他们往往是相辅相成、互相印证的。所以我们不必过度纠结，把他们机械式地分门别类、划清界限。需求虽然是多变的，但一个系统不可能不做修改就满足所有变化，我们需根据当下以及可以预估的未来变更运用恰当的模式，适可而止，以不变应万变才不至于过度设计，模式泛滥。