设计模式学习

设计模式，即Design Patterns，是指在软件设计中，被反复使用的一种代码设计经验。使用设计模式的目的是为了可重用代码，提高代码的可扩展性和可维护性。

设计模式这个术语是上个世纪90年代由Erich Gamma、Richard Helm、Raplh Johnson和Jonhn Vlissides四个人总结提炼出来的，并且写了一本Design Patterns的书。这四人也被称为四人帮（GoF）。

为什么要使用设计模式？根本原因还是软件开发要实现可维护、可扩展，就必须尽量复用代码，并且降低代码的耦合度。设计模式主要是基于OOP编程提炼的，它基于以下几个原则：

一、单一职责原则（Single Responsibility Principle）

一个类应该只有一个发生变化的原因

单一职责原则简称 SRP，顾名思义，就是一个类只负责一个职责。那这个原则有什么用呢，它让类的职责更单一。这样的话，每个类只需要负责自己的那部分，类的复杂度就会降低。如果职责划分得很清楚，那么代码维护起来也更加容易。试想如果所有的功能都放在了一个类中，那么这个类就会变得非常臃肿，而且一旦出现bug，要在所有代码中去寻找；更改某一个地方，可能要改变整个代码的结构，想想都非常可怕。当然一般时候，没有人会去这么写的。

当然，这个原则不仅仅适用于类，对于接口和方法也适用，即一个接口/方法，只负责一件事，这样的话，接口就会变得简单，方法中的代码也会更少，易读，便于维护。

事实上，由于一些其他的因素影响，类的单一职责在项目中是很难保证的。通常，接口和方法的单一职责更容易实现。

单一职责原则的好处：

代码的粒度降低了，类的复杂度降低了。 可读性提高了，每个类的职责都很明确，可读性自然更好。 可维护性提高了，可读性提高了，一旦出现 bug，自然更容易找到他问题所在。 改动代码所消耗的资源降低了，更改的风险也降低了。

二、开闭原则（Open Closed Principle）

一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭

在软件的生命周期内，因为变化，升级和维护等原因需要对软件原有代码进行修改，可能会给旧代码引入错误，也有可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现。
开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统，开闭原则只定义了对修改关闭，对扩展开放。其实只要遵循SOLID中的另外5个原则，设计出来的软件就是符合开闭原则的。
用抽象构建架构，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保证架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了，当然前提是抽象要合理，要对需求的变更有前瞻性和预见性.

三、里氏替换原则（Liskov Substitution Principle）

所有引用基类的地方必须能透明地使用其子类的对象
氏替换原则的意思是，所有基类在的地方，都可以换成子类，程序还可以正常运行。这个原则是与面向对象语言的继承特性密切相关的。

在学习java类的继承时，我们知道继承有一些优点：

子类拥有父类的所有方法和属性，从而可以减少创建类的工作量。 提高了代码的重用性。
提高了代码的扩展性，子类不但拥有了父类的所有功能，还可以添加自己的功能。 但有优点也同样存在缺点：
继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法。 降低了代码的灵活性。因为继承时，父类会对子类有一种约束。
增强了耦合性。当需要对父类的代码进行修改时，必须考虑到对子类产生的影响。 如何扬长避短呢？方法是引入里氏替换原则。

里氏替换原则对继承进行了规则上的约束，这种约束主要体现在四个方面：
1.子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。
2.子类中可以增加自己特有的方法。
3.当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比- 父类方法的输入参数更宽松。(即只能重载不能重写)
4.当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

四、迪米特法则（Law of Demeter）

只与你的直接朋友交谈，不跟“陌生人”说话
其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

五、接口隔离原则（Interface Segregation Principle）

1、客户端不应该依赖它不需要的接口。 2、类间的依赖关系应该建立在最小的接口上。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
接口隔离原则的优点：
接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。
接口隔离原则的实现方法：
在具体应用接口隔离原则时，应该根据以下几个规则来衡量。 根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情

六、依赖倒置原则（Dependence Inversion Principle）

1、上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2、抽象不应该依赖于细节，细节应该依赖于抽象。

创建型模式

创建型模式关注点是如何创建对象，其核心思想是要把对象的创建和使用相分离，这样使得两者能相对独立地变换。

创建型模式包括：

工厂方法：Factory Method
抽象工厂：Abstract Factory
建造者：Builder
原型：Prototype
单例：Singleton

1.工厂方法，抽象工厂

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

工厂模式

2.建造者模式

建造者模式是日常开发中比较常见的设计模式，它的主要作用就是将复杂事物创建的过程抽象出来，该抽象的不同实现方式不同，创建出的对象也不同。通俗的讲，创建一个对象一般都会有一个固定的步骤，这个固定的步骤我们把它抽象出来，每个抽象步骤都会有不同的实现方式，不同的实现方式创建出的对象也将不同。举个常见的例子，想必大家都买过电脑，电脑的生产或者组装其实就是属于建造者模式，我们知道，电脑的生产都需要安装CPU、内存条、硬盘等元器件。我们可以把这个安装步骤抽象出来，至于到底装哪种CPU，比如i5还是i7就是对该抽象安装步骤的具体实现。

建造者模式分为两种，一种为经典建造者模式，另一种为变种建造者模式

参考资料
https://zhuanlan.zhihu.com/p/58093669

3.原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象

4.单例模式

参考
https://blog.csdn.net/jason0539/article/details/23297037/

结构型模式

结构型模式主要涉及如何组合各种对象以便获得更好、更灵活的结构。虽然面向对象的继承机制提供了最基本的子类扩展父类的功能，但结构型模式不仅仅简单地使用继承，而更多地通过组合与运行期的动态组合来实现更灵活的功能。

结构型模式有：

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

1.适配器模式

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
参考资料

2.桥接模式

将抽象部分与它的实现部分分离，使它们都可以独立地变化
参考资料

3.组合模式

将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性
参考资料

4.装饰器模式

动态地给一个对象添加一些额外的职责。就增加功能来说，相比生成子类更为灵活
参考资料

5.外观模式

为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
参考资料

6.享元模式

享元（Flyweight）的核心思想很简单：如果一个对象实例一经创建就不可变，那么反复创建相同的实例就没有必要，直接向调用方返回一个共享的实例就行，这样即节省内存，又可以减少创建对象的过程，提高运行速度。

7.代理模式
为其他对象提供一种代理以控制对这个对象的访问
参考资料
参考资料

行为型模式

行为型模式主要涉及算法和对象间的职责分配。通过使用对象组合，行为型模式可以描述一组对象应该如何协作来完成一个整体任务。

行为型模式有：

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

1.责任链
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

2.命令模式
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作.

3.解释器

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

4.迭代器模式

提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。

5.中介模式
用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

6.备忘录模式

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。

7.观察者模式

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

8.状态模式

允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

9.策略模式

定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
策略模式的核心思想是在一个计算方法中把容易变化的算法抽出来作为“策略”参数传进去，从而使得新增策略不必修改原有逻辑

10.模板方法
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

模板方法（Template Method）是一个比较简单的模式。它的主要思想是，定义一个操作的一系列步骤，对于某些暂时确定不下来的步骤，就留给子类去实现好了，这样不同的子类就可以定义出不同的步骤。

11.访问者模式

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

访问者模式（Visitor）是一种操作一组对象的操作，它的目的是不改变对象的定义，但允许新增不同的访问者，来定义新的操作。