title: 设计模式笔记-大纲
date: 2019-04-25 09:49:37
tags: 设计模式

作者：muggle

设计模式的分类

创建型模式

共五种：

• 工厂方法模式
• 抽象工厂模式
• 单例模式
• 建造者模式
• 原型模式

结构型模式

共七种：

• 适配器模式
• 装饰器模式
• 代理模式
• 外观模式
• 桥接模式
• 组合模式
• 享元模式

行为型模式

共十一种：

• 策略模式
• 模板方法模式
• 观察者模式
• 迭代子模式
• 责任链模式
• 命令模式
• 备忘录模式
• 状态模式
• 访问者模式
• 中介者模式
• 解释器模式

设计原则

设计模式的最终目的是为了实现代码设计的六大基本原则的，我们在使用设计模式的时候千万要记住这一点，不用为了使用设计模式而去强行套设计模式

单一职责原则

不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。

当需求变化时，将通过更改职责相关的类来体现。如果一个类拥有多于一个的职责，则多个职责耦合在一起，会有多于一个原因来导致这个类发生变化。一个职责的变化可能会影响到其他的职责，另外，把多个职责耦合在一起，影响复用性。

单一职责原则解决的问题：

• 降低类的复杂度；
• 提高类的可读性，提高系统的可维护性；
• 降低变更引起的风险（降低对其他功能的影响）。

里氏替换原则

任何基类可以出现的地方，子类一定可以出现。

只有当子类可以替换掉父类， 代码功能不受到影响时，父类才能真正被复用， 而子类也能够在父类的基础上增加新的行为；从而达到代码复用与扩展的目的；里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。

里氏替换原则解决的问题：

• 增强程序的健壮性， 版本升级时也可以保持非常好的兼容性。
• 提高代码复用率

依赖倒置原则

这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。

开闭原则

对于引用的模块尽量去扩展，而不是去修改它，也就是所谓的对扩展开放对修改关闭。开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则，抽象化是开闭原则的关键。

接口隔离原则

接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。 根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可

迪米特原则

一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

设计模式解析

首先允许我提一点建议，有不少设计模式的教程喜欢拿生活中一些事物举例子，比如什么什么奥迪汽车，宝马，汽车工厂这种。这种方式确实能让人更加直观的的体会到一个设计模式的用法和作用，但是我以前这样学的后果就是——看啥都像设计模式，想往设计模式里面套又套不出个所以然来。实际上有的设计模式结构是由好几个角色组成，该如何去写怎么命名都是确定的有理有据的，你光记住生活中的一个例子然后平时写代码去套这个例子，你会有种无从下手的感觉。我们应该把每个设计模式的使用场景结构都记住，但是这样死记难记不说，还很难做到活学活用。我的的建议是结合源码去记，这样你能根据源码中的例子依瓢画葫芦写出自己想要的设计模式出来，我接下来对设计模式的讲解也是结合源码进行讲解的。

然后，我个人建议是能不用设计模式的地方就不用设计模式。并不是因为设计模式不好，一个设计得好的设计模式确实可以减少我们工作量和代码维护成本，但是一个设计不好的设计模式使用起来代价巨大。要知道设计模式的最终目的是减少我们的工作量，不要为了设计模式而设计模式。一个垃圾的设计模式的缺点：代码维护成本翻倍，因为会凭空多了好多莫名其妙的类；代码读不懂，你设计模式用的乱七八糟，别人只会感觉你的代码毫无逻辑，绕来绕去。

一个好的设计模式，首先要用对场景，然后命名要规范，要让别人一看命名就知道你用的什么设计模式，然后根据设计模式去找相关联的类，这样别人脑海里才能形成一个脉络，有点没法按设计模式规范命名的地方也请加上注释，不然让别人猜你的代码写了些啥，用的啥设计模式吗？
个人公众号：