设计模式 - 前言
当我们学习时，到底在学习什么
无论学习什么内容，我们基本都是从几个维度循序渐进去了解和熟悉，至到融入记忆；当再遇到类似问题时，这些曾经学习的知识能立马涌现到脑海，以用于解决对应的问题；这些维度主要分为以下几点：
- 是什么
- 为什么
- 能解决什么
- 如何实现
- 如何使用
- 什么场景下使用
下面我们学习设计模式，也将从这几个维度进行阐述；
什么是设计模式
在学习设计模式之前，我们先从宏观角度分析，它到底是什么；
- 设计模式：
- 设计过程中可以反复使用 的、可以解决特定问题 的设计方法。
从上面的概念可知，设计模式是可以反复使用，并且可以用来解决问题的方法；
无论如何形容与修饰，它的本质是：一种方法，一种解决问题的套路；
拓展
因此任何可以结总提炼，并用于解决一类问题的解决方案都可以称之为模式;
本系列主要指代码编写中的模式，为狭义的模式；
产生背景
在开发和代码书写时，总会遇到一些经常出现的问题，以及基于这些问题的一些通用解决方案；
目的
把常见问题的通用解决方案经总结和提炼，形成固定的解决方案和套路；
在遇到这些常见的问题时，可以不假思索的直接使用那些已经经过总结的解决方案和套路；
设计模式的六大原则
设计模式是对解决问题的方案总结；这些模式遵循以下原则：
- 开闭原则
- 开闭
- 一开一闭：对扩展开放，对修改封闭；它是以下其它所有原则的基础准则；
- 什么是扩展：
- 所谓扩展，即在原有功能基础上，增加新的功能或新的特性；
- 什么是修改：
- 所谓修改，即对原有功能进行变更
- 为什么对扩展开放，对修改封闭：
-
A: 可以无限增加新功能
扩展的目的是，可以使代码无限拓展，功能无限增加，需求无限成长；这是一个项目或系统随着时间不断成长的必要条件； -
B: 不影响原有功能
在扩展项目或系统的前提条件下，不能影响原有功能，否则可能导致牵一发而动全身，无法集中力量投入新业务和新需求中；
- 单一职责原则
- 概念：
- 一个类应该只有一个发生变化的原因
白话：即一个类只承担一个维度的功能；不要让一个类承担太多维度的功能；同理，一个方法，只执行一个事件的处理；
示例：一个系统的用户及登录功能
UserService 只应该负责 用户本身的处理（增、删、改、查）,不应承担登录相关的功能；
LoginService 可以依赖UserService提供的服务，对外提供登录，但本身不应该处理用户信息；
里氏替换原则
任何基类可以出现的地方，子类一定可以出现；对于面向对象的开发者，可以简单的理解为：继承；防止陷入生涩的概念之中；
依赖倒转原则
面向接口编程，依赖于抽象而不依赖于具体。写代码时用到所需要依赖时，不应该与具体类交互，而应该与具体类的接口交互。
对于面向对象的开发者，可以简单的理解为：面向接口编程；
- 原因：
- 接口是入口，是对接的边界，实现是扩展，只要接口不变，就不影响原有功能; 但实现可以无限扩展，就可以实现无限的功能
接口隔离原则
迪米特法则
- 概念
- 迪米特法则：最少知道原则；即一个类对自己依赖的类知道的越少越好；即每个类都应该自治，只需要对外提供必要的接口进行相互调用即可；
- 目的：
- 类与依赖之间松耦合，
- 合成复用原则
继承是一种扩展，但是与基类却有一定程度的耦合；合成复用则一种更大的松耦合方式；
- 概念
- 通过聚合、引用的方式实现扩展，而不是使用继承；
23种设计模式
23种设计总体可以分为三类：
-
-
创建型模式
-
创建型模式：主要用于创建对象；
- 单例模式
- 工厂方法模式
- 抽象工厂模式
- 建造者模式
- 原型模式
-
-
结构型模式：
-
结构型模式：主要用于改变类的结构
- 适配器模式
- 装饰者模式
- 代理模式
- 外观模式
- 桥接模式
- 组合模式
- 享元模式
-
-
行为型模式：
-
行为型模式：主要用于改变行为（逻辑）
- 策略模式
- 模板方法模式
- 观察者模式
- 迭代子模式
- 责任链模式
- 命令模式
- 备忘录模式
- 状态模式
- 访问者模式
- 中介者模式
- 解释器模式