设计模式总结

一、概念和分类

概念：设计模式(Design Pattern)是代码设计经验的总结。

作用：使用设计模式是为了可重用代码、让代码更容易被他人理解、提高代码的可靠性。

优点：①提供了一套通用的设计词汇和一种通用的语言，以方便开发人员之间进行沟通和交流；②使得设计方案更加通俗易懂，更加简单方便地复用成功的设计和体系结构；③ 使得设计方案更加灵活，且易于修改，将提高软件系统的开发效率和软件质量，在一定程度上节约设计成本。

分类

根据目的（模式是用来做什么的）可分为创建型，结构型和行为型三类：
创建型模式：主要用于创建对象。

（单例模式、原型模式、抽象工厂模式、建造者模式、工厂模式）
结构型模式：主要用于处理类和对象的组合。

（适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式）
行为型模式：主要用于描述类或对象如何交互和怎样分配职责。

（模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式）

观察者模式：观察者模式它是用于建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应的作出反应。

观察者模式的主要角色
1、Subject：抽象主题（抽象被观察者），抽象主题角色把所有观察者对象保存在一个集合里，每个主题都可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察者对象。
2、ConcreteSubject：具体主题（具体被观察者），该角色将有关状态存入具体观察者对象，在具体主题的内部状态发生改变时，给所有注册过的观察者发送通知。
3、Observer：抽象观察者，是观察者的抽象类，它定义了一个更新接口，使得在得到主题更改通知时更新自己。
4、ConcrereObserver：具体观察者，实现抽象观察者定义的更新接口，以便在得到主题更改通知时更新自身的状态。在具体观察者中维护一个指向具体目标对象的引用,它存储具体观察者的有关状态,这些状态需要与具体目标保持一致.

1)、 观察者模式的优点：

降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。
被观察者发送通知，所有注册的观察者都会收到信息【可以实现广播机制】
2)、 观察者模式的缺点：

如果观察者非常多的话，那么所有的观察者收到被观察者发送的通知会耗时
如果被观察者有循环依赖的话，那么被观察者发送通知会使观察者循环调用，会导致系统崩溃

观察者模式常见的应用场景

1、当一个对象状态的改变需要改变其他对象时。比如，商品库存数量发生变化时，需要通知商品详情页、购物车等系统改变数量。
2、一个对象发生改变时只想要发送通知，而不需要知道接收者是谁。比如，订阅微信公众号的文章，发送者通过公众号发送，订阅者并不知道哪些用户订阅了公众号。
3、需要创建一种链式触发机制时。比如，在系统中创建一个触发链，A 对象的行为将影响 B 对象，B 对象的行为将影响 C 对象……这样通过观察者模式能够很好地实现。
3、微博或微信朋友圈发送的场景。这是观察者模式的典型应用场景，一个人发微博或朋友圈，只要是关联的朋友都会收到通知；一旦取消关注，此人以后将不会收到相关通知。
4、需要建立基于事件触发的场景。比如，基于 Java UI 的编程，所有键盘和鼠标事件都由它的侦听器对象和指定函数处理。当用户单击鼠标时，订阅鼠标单击事件的函数将被调用，并将所有上下文数据作为方法参数传递给它。

二、六大原则

1、单一职责原则（单一功能原则）

一个类一个方法

单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分，即尽量保证每个类里面只有一个方法，只能实现一种功能；

如登录注册、日志、邮件等功能，应该分为多个类实现，而不是糅合在一个类里面

优点：①降低类的复杂度；②提高类的可读性；③提高系统的可维护性；④变更引起的风险降低

2、开放封闭原则

拓展是开放的，修改是封闭的

新增方法，代码的改变不是修改原有的类，因为会带入新的问题，解决方法是使用抽象接口抽象约束，实现类去实现这个抽象方法，不同的实现类可以重新抽象方法来完成不同的功能；如银行是一个接口，它有一个处理方法；转账类可以实现这个方法完成转账操作；存款，取款也是；

3、 里氏替换原则

多态

只要父类出现的地方，子类就可以出现，替换为子类后不会产生任何错误和异常；

尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，在运行时再确定其子类类型，用子类实例来替换父类实例。

所有引用基类（父类）的地方必须能透明地使用其子类的对象。

4、依赖倒置原则

接口或抽象类不依赖于实现类，而实现类依赖接口或抽象类；

如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。依赖倒置就是为了解决耦合。让程序依赖于抽象。

5、迪米特原则（最少知识原则）

一个类对自己需要耦合的类应该知道的最少，你内部多么复杂和我没关系，我只对你提供的public方法感兴趣。这样的话，如果一个系统符合迪米特法则，那么当其中某一个类发生修改时，就会尽量少地影响其他模块，降低系统的耦合度，使类与类之间保持松散的耦合关系。

6、 接口隔离原则

建立单一接口而不是建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。