课程介绍
大家好~，我是专治胃不好的关阿姨，本教程我们来学习设计模式，保证大家学习完后药到病除，吃嘛嘛香。
说起设计模式，很多同学其实都听说过，工作中或多或少也都有接触，只不过没有系统的总结或者刻意的使用，那今天阿姨就和大家来聊聊设计模式。首先要和大家明确一点：**设计模式不依赖语言，其实设计模式，好多人称之为 " Java设计模式 "，**但其实设计模式并不是 Java 的专利，它不依赖语言，其它面向对象的编程语言，同样适用，例如 C++、JavaScript 等，这是首先要和大家明确的一点，Java 是典型的面向对象的编程语言，所以本教程以 Java 为基础来讲解设计模式。
课程内容
凡事预则立，不预则废，再开始学习一门新的课程之间，我们首先要来明确一下学习的内容及路线。
- 设计模式七大设计原则（单一职责，接口隔离，里式替换，依赖倒置原则，开放封闭原则等）各种设计模式的基础 (即：设计模式为什么 这样设计的依据）
- 认识UML类图以及类图六大关系（UML类图是我们后面讲解设计模式经常用到的，类图关系也是设计模式必备的知识/技能）
- 设计模式的分类以及二十三种设计模式全面解析
本节内容目标
首先，在正式的内容开始之前，我们首先要明确以下两点
- 为什么要学习设计模式，也就是设计模式的重要性
- 设计模式的产生背景以及概念
为什么要学习设计模式？
设计模式是程序员自身修炼的宝典，敲代码就像是招式，设计模式更像是内功。就像令狐冲练了独孤九剑，在内力全无时，虽然能胜过许多二流高手，但遇到别人纯内力打击，他就扛不住了。而编程也是一样的道理，因为平时大家接到开发任务，首要目标是实现功能，而且现在的节奏~，时间紧，任务重，大家没有，可能也来不及做其他的考虑，所以，大部分程序员写的代码，其实可维护性，可读性都很差，类之间的关系非常复杂，没有条理，那例如以后要增加新的需求，现有的程序如何进行变动成本最低？如何保证新的功能模块不会对原来的项目产生影响？所以随之而来的就是设计模式，所以类似大家这样有一定工作经验的开发人员，了解以及进一步掌握设计模式是非常有必要的。
当然，设计模式，大家可以通俗理解为是前辈程序员在大量开发中累积的经验，掉了大量的头发，然后归纳为了这些设计模式，设计模式绝不是代表了绝对的开发真理，在问题面前应该灵活变通，当你的代码类结构合理， 易于维护 ，可扩展性强，那么设计模式的目的就已经达到了，切记不要过渡的使用设计模式，为了用而用。
设计模式的产生背景
设计模式的概念
设计模式的重要性
- 设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。
- 设计模式是为了让软件（程序）具有更好的代码重用性，可读性，可扩展性，可靠性
理论听着云里雾里，那到底是什么意思呢？举个栗子，何为具有更好的可靠性呢？
- 代码重用性：即相同功能的代码，不需要多次编写，可以重复使用
- 可读性：即编码的规范性，便于其他程序员阅读和理解
- 可扩展性：即当需要增加新功能时，成本低，也称为可维护性
- 可靠性：即代码强壮性，当增加新的功能时，对原有的功能没有影响
其实说到底，就是让程序呈现出高内聚，低耦合的特性（说人话..........）
内聚主要描述模块内部，耦合主要描述模块之间的关系，当然模块的粒度可大可小（小到一个类 大-到一个系统）
- 高内聚 一个功能模块内部的元素，关联越强，则内聚越高，模块的单一性更强，一个模块应当尽可能独立完成某个功能
- 低耦合 功能模块和功能模块之间耦合性很低，例如：T 负责两个不同的职责：职责 P1，职责 P2。当由于职责 P1 需求发生改变而需要修改类 T 时，有可能会导致原本运行正常的职责 P2 功能发生故障，也就是说职责P1和P2被耦合在了一起。例如下图，我们假设这样一个场景，发货系统发货，写入消息队列，订单系统这边订阅消息队列里的消息，如果订单系统出现故障，不影响发货系统正常写入消息队列，利用了消息中间件，两个系统之间的耦合性大大降低。
设计原则
接下来阿姨带大家进入一个新的世界，正式进入到设计模式七大原则............................
- 单一职责原则（Single responsibility principle，SRP）
- 开放封闭原则（Open–closed principle，OCP）
- 里氏替换原则（Liskov substitution principle，LSP）
- 接口隔离原则（Interface segregation principle，ISP）
- 依赖倒置原则（Dependency inversion principle，DIP）
PS:这些原则并不是孤立存在的，它们相互依赖，相互补充滴。
|
名称 |
设计原则简介 |
重要性 |
|
单一职责原则 |
**首先，单一职责是由基于高内聚演化而成。**类的职责要单一，不能将太多的职责放在一个类中 |
★★★★☆ |
|
开闭原则 |
开放封闭原则：OCP(Open Close Principle)软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能 |
★★★★★ |
|
里氏替换原则 |
在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象 |
★★★★☆ |
|
依赖倒置原则 |
要针对抽象层编程，而不要针对具体类编程 |
★★★★★ |
|
接口隔离原则 |
使用多个专门的接口来取代一个统一的接口 |
★★☆☆☆ |
|
合成复用原则 |
在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系 |
★★★★☆ |
|
迪米特法则 |
一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互 |
★★★☆☆ |
