23种设计模式

设计模式的六大原则

一、开闭原则（Open Close Principle）

对扩展开放，对修改关闭。

在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类。

二、里氏代换原则（Liskov Substitution Principle）

子类型必须能够替换掉它们的父类型。由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。

面向对象设计的基本原则之一。
里氏代换原则中说， 任何基类可以出现的地方，子类一定可以出现。 LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。
里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

三、依赖倒转原则（Dependence Inversion Principle）

高层模块不应该依赖低层模块，两个都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。

要针对接口编程，不要针对实现编程。该原则可以说是面向对象设计的标志，编写时考虑的是如何对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口。

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

使用多个隔离的接口，比使用单个接口要好。从而降低类之间的耦合度。

针对类是 “单一职责原则” ：就一个类而言，应该仅有一个引起它变化的原因。

五、迪米特法则，又称最少知道原则（Demeter Principle）

一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

该原则其根本思想，是强调了类之间的松耦合；类之间的耦合越弱，越利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

六、合成复用原则（Composite Reuse Principle）

尽量使用合成/聚合的方式，而不是使用继承。

聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；
合成则是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
优先使用对象的合成/聚合将有助于你保持每个类被封装，并被击中在单个任务上，这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

UML例图

一、常见的几种关系

• ‘+’：表示public；
• ‘-’：表示private；
• ‘#’：表示protected；

1.泛化（Generalization）：继承关系

2.实现（Realization）：类与接口的关系

3.关联（Association)：拥有的关系

它使一个类知道另一个类的属性和方法（成员变量）；
关联可以是双向的（老师与学生），也可以是单向的（学生与课程）。
双向：两个箭头或者没有箭头；
单向：指向被拥有者。

4.聚合（Aggregation）：整体与部分的关系

是关联关系的一种，是强的关联关系；部分可以离开整体而单独存在。

5.组合(Composition)：整体与部分的关系

是关联关系的一种，是比聚合关系还要强的关系；部分不能离开整体而单独存在，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。例如：没有公司就不存在部门。

6.依赖(Dependency)：使用的关系

一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖。
例如：局部变量、方法的参数或者对静态方法的调用；

二、各种关系的强弱顺序

泛化（继承） = 实现（类与接口） > 组合（整体与部分，部分不能离开整体） > 聚合（整体与部分，部分可以离开整体） > 关联（拥有） > 依赖（使用）

三、示例图

创建型模式

工厂方法模式

结构：

抽象工厂模式

结构：

生成器模式

结构：

原型模式

结构：
基本实现：

原型注册表实现：

单例模式

结构：

结构型模式

适配器模式

应用场景：

• 电源适配器转换头；
• XML 转换为 JSON 格式的适配器。

结构：
对象适配器：

类适配器：

桥接模式

应用场景：
假如你有一个几何形状类：圆形、方形 。扩展颜色：红色、蓝色。 需要创建四个类才能覆盖所有组合。

结构：

组合模式

如果应用的核心模型能用树状结构表示， 在应用中使用组合模式才有价值。

应用场景：
假如你有两类对象： ​ 产品、盒子 。 盒子又包含：多个产品或者几个较小的盒子。小盒子同样又包含一些产品或更小的盒子，以此类推。

结构：

装饰模式

应用场景：
觉得冷时， 你可以穿一件毛衣。 如果还冷， 你可以再套上一件夹克。 如果遇到下雨， 你还可以再穿一件雨衣。 所有这些衣物都 “扩展” 了你的基本行为， 但它们并不是你的一部分， 如果你不再需要某件衣物， 可以方便地随时脱掉。

结构：

外观模式（门面模式）

应用场景：

• 当你通过电话给商店下达订单时， 接线员就是该商店的所有服务和部门的外观。 接线员为你提供了一个同购物系统、
  支付网关和各种送货服务进行互动的简单语音接口；
• 日志框架slf4j的实现。

结构：

享元模式

仅在程序必须支持 大量对象 且 没有足够的内存 容量时使用享元模式。对象中 包含可抽取且能在多个对象间共享的重复状态。

应用场景：
射击游戏中， 多个数组成员变量来存储每个粒子（子弹）的坐标、 方向矢量和速度。另一个数组来存储指向代表粒子的特定享元的引用。 这些数组必须保持同步， 这样你才能够使用同一索引来获取关于某个粒子的所有数据。

结构：

代理模式

应用场景：

• spring中@Transaction、@Async等。

结构：

行为模式

责任链模式

应用场景：

• 给技术支持打电话时你可能得应对多名接听人员。
  

结构：

命令模式

应用场景：
餐厅点餐， 服务员记下你点的食物， 写在一张纸上（订单），并送给厨师，厨师做好后。 服务员检查后将食物放到了你的桌上。
那张纸就是一个命令， 它在厨师开始烹饪前一直位于队列中。 命令中包含与烹饪这些食物相关的所有信息。 厨师能够根据它马上开始烹饪， 而无需跑来直接和你确认订单详情。

结构：

迭代器模式

应用场景：

• 集合Iterator的实现；
• 你计划在罗马游览数天， 参观所有主要的旅游景点，你可以：自由漫步、 智能手机导航或真人向导，这都是由众多罗马景点组成的集合的迭代器。
  

结构：

中介者模式

应用场景：

• 飞行器驾驶员之间不会通过相互沟通来决定下一架降落的飞机。 所有沟通都通过控制塔台进行。

结构：

备忘录模式

应用场景：

• 当用户触发撤销操作时， 历史类将从栈中取回最近的备忘录， 并将其传递给编辑器以请求进行回滚。 由于编辑器拥有对备忘录的完全访问权限， 因此它可以使用从备忘录中获取的数值来替换自身的状态。

结构：
基于嵌套类的实现：

基于中间接口的实现：

封装更加严格的实现：

观察者模式

应用场景：

• 杂志和报纸订阅。
  

结构：

状态模式

应用场景：

• 手机的按键和开关会根据设备当前状态完成不同行为，解锁状态时， 将执行各种功能；锁定状态时，将解锁屏幕；电量不足时，将显示充电页面。

结构：

策略模式

应用场景：

• 各种前往机场的出行策略；
  

结构：

模板方法模式

应用场景：

• 可对典型的建筑方案进行微调以更好地满足客户需求；
  
• 抽象类实现共同业务后，调用抽象方法，各个子类实现抽象方法。

结构：

访问者模式

应用场景：

• 优秀的保险代理人总能为不同类型的团体提供不同的保单。
  

结构：