设计模式-概论

概述

设计模式从定义来说，是指软件开发过程中，有很多重复的、经常出现的场景，于是我们为这些常见的场景设计了最佳实践。当我们遇到类似场景时，可以使用这些模式，能达到高内聚、低耦合、易读可维护等最佳实践。
设计模式在知识上分为两大块，一块是抽象的、从上层进行指导的原则；另一块是可以直接落地的、有代码范例的23种设计模式。指导原则虽然抽象，却是最核心的，设计模式本质是在不同场景下对指导原则的各种实现。

设计模式的缺点

推荐文章：圣杯与银弹，没用的设计模式-面向信仰编程

1. 23种设计模式，容易让编程变得生硬
2. 设计模式，往往是用更多量的代码实现解耗，大量使用设计模式，会让代码星很多，反而导致代码可读性变差
3. 单纯学习设计模式，并不能很好转化为编码能力。编码的能力需要大量代码的阅读，在阅读中吸收优秀编码规范。这样就导致，代码阅读多了，即使不学习设计模式，也懂得很好优秀设计；代码阅读不多，即使学习设计模式，编码能力一样不能提高很多
4. 对设计模式的学习，关键在于将指导原则牢记于心，在编码时会想着各类指导原则，在遇到合适场景时才考虑具体的设计模式，避免过度设计

指导原则

原则名称	英文	解释
单一职责原则	SRP	1. 一个类只负责一个或者一类功能。不要设计大而全的类，要设计粒度更小、功能单一的类。 2. 单一职责原则是为了实现代码的高内聚、低耦合、提高代码的复用性、可读性、可维护性。
开闭原则	OCP	1. 添加一个新功能，应该是在已有代码上扩展（模块、类、方法），而不是修改。 2. 在不同的代码粒度下，扩展和修改是相对的。关键是我们要有扩展的意识，避免改动原来的代码。在复杂项目中，一处代码可能被多个地方调用，修改一处代码面临回归成本和隐藏的风险。 3. 大部分设计模式，都是通过在一开始的合理架构，使得后续新功能可以少修改原有代码，直接新增新功能代码。例如，装饰器模式、策略模式、观察者模式。
里式替换原则	LSP	1. 子类对象能够替换程序中父类出现的任何地方，并且保证原来的逻辑行为不变及正确性不变。 2. 里式替换原则是一种思想，在实现时已经有继承、接口等方式。关键在于按照协议来设计，调用方可以只关注父类提供的功能，子类也只需要关注父类约定的功能，实现调用方和子类的解耦。
接口隔离原则	ISP	1. 调用方不应该被强迫依赖它不需要的接口。 2. 简单理解，不要暴露调用方不关心的接口，接口功能中不应该有调用方使用不到的逻辑 3. 也是一种思想，思想是用来指导设计，架构时并没有完美实现->肯定会多暴露的，只是尽量少暴露些。
依赖反转原则	DIP	1. 高层模块不要依赖低层模块，高层和低层模块应该通过抽象来互相依赖。并且抽象不应该依赖具体实现，具体实现应该依赖抽象 2. 在实现时，需要在高层和低层之间加一层抽象接口。低层实现这个抽象，高层只关注这个抽象。 3. - 控制反转：一种指导框架设计的思想。正常程序执行流程是由程序员指定从Main函数开始，而 - 通过控制反转，程序执行流程会由框架指导，我们只需要实现中间的业务逻辑。 - 依赖注入：业务对象依赖的下层实例，不需要业务自己new()生成，而是由框架生成并注入 - 依赖注入框架：实现了依赖注入功能的框架，如Spring，可通过配置文件实现依赖注入 - 依赖反转：指高层不应该直接依赖低层，高层和低层之间需要有一个抽象，高层使用抽象，低层实现抽象
KISS原则		1. 常见解释是：Keep It Simple And Stupid。尽量保持代码简单 2. 很认可的一项原则，实现代码时，要尽量简单。实现功能时，不要有多余代码。 - 不要重复造轮子 - 不要过度优化考虑代码可读性3.类似原则：YAGNI - 考虑代码可读性 3. 类似原则：YAGNI - You Ain’t Gonna Need It.你不需要它 - 侧重于不要写不需要的代码，不要提前大量设计
DRY 原则		1. Don’t Repeat Yourself.不要重复你的代码 2. 这里的重复，指业务模块的功能上，不是具体代码。例如两个方法不同实现方式，但是实现的业务逻辑一样，这算重复；如果两个方法代码一样，但是用于不同业务逻辑，这不算重复 3. 总的来说，就是减少冗余代码
迪米特法则	LOD	1. 每个模块应该只了解和它关系密切的模块的有限知识。不该有直接依赖关系的类之间，不要有依赖；有依赖的类之间，只应该依赖必要的接口。 2. 我认为和接口隔离原则有点类似，可能侧重点不同。接口隔离原则用于设计自己的接口，迪米特法则用来描述整个架构类与类的关系。