研磨设计模式读书笔记

写在前边：准备写一篇长文结束，不分开写了，找的时候麻烦。各位想看对应的设计模式，直接点击目录查看即可。

如果有哪里写的不好，或者表达不准确，或者描述错误，理解错误：欢迎各位私信、留言给出意见。

由于权限问题，原著无法放在这里，各位想看原著需要在网上找资源了。

本人写这个篇文章的时候，工作经验半年左右，其中可能有许多不到位的地方，如果各位看到哪里不合适，希望可以多多指教，希望不会因为我的错误理解误人子弟。

常见的设计原则

1、单一职责原则

一个类、方法应该仅有一个原因可以让它变化

2、开闭原则

一个类应该对扩展开放，对修改关闭。

开闭原则的要求是：类的行为是可扩展的，而且是在不修改已有代码的情况下进行扩展

实现开闭原则的关键就在于合理的抽象、分离出变化与不变化的部分，为变化部分预留下可扩展的方式。比如：钩子方法或动态组合对象

3、里氏替换原则

子类必须可以能替换掉父类

4、依赖倒置原则

要依赖抽象：

• 高层模块不应该依赖底层模块，二两都应该依赖抽象

• 抽象不应依赖具体的实现，具体应该以来抽象

层次化调用的时候，一般高层模块包含对业务功能的处理和业务策略的选择，应该被重用，是高层模块去影响底层的具体实现。就像国家出台一项政策，底层的人会去适应这个政策一样。

底层接口应该是高层提出的，然后由底层实现。也就是说底层接口的所有权（构建权）在于高层模块，因此是一种所有权的倒置。

5、接口隔离原则

接口隔离原则，指的是：一个接口包含的方法不应该过多，应该只包含和该接口相关的方法。不应该有其他的无关的“垃圾方法”。这些方法对客户来说，就是一种接口污染。

包含很多“垃圾方法”的接口应该被分离，方便客户的使用。

6、最少知识原则

在设计系统的时候，应该尽量减少对象之间的交互，对象之和自己的朋友进行交流。从而松散类之间的耦合。

让我想起了起义，起义的时候，就是很多人之间的交互，一个人出问题，可能这一堆人都要出问题，一呼百应。

UML基础

1、UML是什么？

UML是一种标准的图形化建模语言，是面向对象分析和设计的一种标准化表示

2、类图

类图是静态视图的图形化表达

类图顾名思义就是一个类的图形化表示。类中有的东西，都可以在类图中表示出来。

3、关系

这里只介绍几种关系：

1. 关联
2. 泛化
3. 实现
4. 依赖

1、关联

1、普通关联

解释：

带 × 的一端表示关联的发起方，带→ 的一端表示被关联的一方。

数字的含义

形式	含义
空	1个对象
n	n个对象
m…n	m到n个对象
*	多个对象

上图的含义为：
一个人可以拥有0-多台计算机，而一台计算机只能属于一个人，计算机与人之间构成关联关系。

２、递归关联

如果一个类和本身有关联，那这种关系就叫做递归关联。

表示形式与普通关联差别不大，只是关联对象从两个变成了自身关联自身。

3、聚合关联

聚合是一种特殊的关联。如果类与类之间是 整体与部分 的关系，使用聚合来表示

比如：公司 与 员工，班级 与 学生。

聚合又可以分为：普通聚合、共享聚合、复合聚合

1、普通聚合

表示 ”整体与部分“ 。两种表示

菱形在表示关联关系的那一端。两种表示方法都可以。

2、共享聚合

简单来说就是：组成者与被组成者形成多对多关系。
譬如说：学生可以组成学习兴趣小组，学习兴趣小组由学生构成，但是一个学生可以加入多个学习兴趣小组，一个学习兴趣小组中可以有多个学生，双方构成多对多的关系，而且是部分和整体的关系。这是就被称为共享聚合。

当然，表示形势中，可以加上箭头。

3、复合聚合

如果构成整体的部分，完全隶属与整体，那么这样的聚合称为复合聚合。也叫组成。
比如在写类的时候，属性和方法构成了一个类。每个属性、方法都是组成类的一部分。
再比如完成一个图形界面的时候，图形界面的按钮、文本框、label等组件与图形界面也构成组成关系，各个组件都是图形界面的组成部分。

在整体的这一端，使用是一个实心的菱形表示。
如果整体对象不存在，那么部分对象其实也就没有了存在的意义/前提。如果一个类消失了，类中的属性、方法也不会存在了。如果图形界面消失了，各个部分在这个界面中存在的意义也就没有了。
所以整体与部分之间具有非常强烈的包含关系。

2、泛化关系

泛化关系又称作通用化或继承，大多是用来描述继承关系的。

3、实现关系

听名字应该就要可以明白，实现关系描述的是接口和实现类的关系。

4、依赖关系

依赖关系的描述是：如果某个对象的行为和实现，需要受到另外对象的影响，那么就说这个对象依赖与其他对象。
严格来说，基本有关联的地方，都有依赖。
通常来说：两个对象之间建立了关系，直接使用或是当作参数传入，或是作为属性出现，都是可以称为依赖关系。

顺序图

这里只简单说明一下，因为原著中的附录中有提到。

顺序图中消息的表示方式：

这些是前置知识，接下来就是正餐了

设计模式

1、 设计模式是什么？

设计模式：是指在软件开发中，经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案。

注意描述中的用词：是用于解决在特定环境下、特定问题 的 解决方案

设计模式是解决某些特定问题的方案，这也就是说，设计模式不是万能的，只能解决某些特定问题，因为这些问题在工程设计中经常出现，所以出现了解决这些问题的一套解决方案------设计模式。

跟我们在做数学题时常用的一些解题套路有些相似。

2、设计模式

这部分将直接对原书的模式讲解进行，如果各位想要看该模式的具体场景、详解、模式的案例请阅读原书。
说人话就是：这里将直接对模式进行总结，不会仔细的讲解模式。如果有哪里总结不到位的，各位可以留言指正，将不胜感激。

1、简单工厂

工厂，具有这样的功能：对原料进行加工处理，制造出规范化的一些产物。
比如：手机组装工厂。原料是单独的一些手机部件，产出的就是规范化的手机。手机组装工厂不会去区分是什么牌子的手机，只是负责组装手机。

产出的手机，就相当于JAVA中的接口。是一个定义，规范。具体的细节，实现都是由工厂去组装完成的。工厂就是用来制造东西。

简单工厂：提供一个创建对象实例的功能，而使用者无须关心实例具体的实现。被创建的实例类型可以是接口、抽象类，也可以是具体的类。

简单工厂，我理解的更像是一个可以创建实例对象的工具类。

简单工厂的特点：

• 调用者不直接通过 new 的方式创建实体类，而是通过简单工厂，让工厂创建实体类，返回接口
• 创建实体类采用的实现类，可以通过参数、配置文件、数据库、运行时获取等方式传递给工厂
• 简单工厂做的是：调用者直接使用抽象，工厂选择具体实现。

简单工厂的优点：

• 帮助封装
  简单工厂虽然简单，但是确实实现了组件的封装，让使用者可以面向接口编程。
• 解耦
  通过简单工厂，实现了客户端和具体实现类的解耦。客户端不需要知道接口具体是谁实现的，也不需要知道接口是如何实现的，只需要直接获取它需要的接口对象即可。

简单工厂的缺点：

• 可能增加客户端的复杂度
  如果通过客户端的参数选择具体的实现类，那么就必须让客户端理解每个参数所代表的具体功能和含义。这样会增加客户端的使用难度。

简单工厂的本质：

简单工厂的本质是：选择实现

简单工厂的重点：选择。
具体的实现有实现类去完成。简单工厂的职责在于：选择一个合适的实现类去实现，根据客户端的需要去选择合适的实现类。

简单工厂的难点：如何选择
简单工厂在选择实现的时候，需要一个“信号”去决定选择哪一种实现。这个“信号”是实现简单工厂的难点。这个“信号”可以由客户端传参传过来，可以使用配置文件读取，还可以使用内存中的值，数据库中的值…等等的方式，需要选择一种合适的方式去传递这个“信号”。

何时使用简单工厂

• 想要完全的封装隔离具体实现，让外部只能通过接口操作封装类。
• 想要把对外创建对象的职责集中管理和控制。

外观模式