23设计模式之 --------- 什么是设计模式？
什么是设计模式？
- 什么是设计模式
- 💙 GOF 23🧡（设计模式介绍）
- 💛设计模式OOP七大原则
- 总原则－开闭原则
- 里氏替换原则（Liskov Substitution Principle）
- 依赖倒转原则（Dependence Inversion Principle）
- 单一职责原则
- 接口隔离原则（Interface Segregation Principle）
- 迪米特法则（最少知道原则）（Demeter Principle）
- 合成复用原则（Composite Reuse Principle）
（后续具体设计模式章节都会引用此文章超链接进行关联）
什么是设计模式
设计模式：其实就是用来解决面向对象的一系列的问题的；他是一套可复用可维护性可读性稳健性及其安全性于一身的一套解决方案；
23种设计模式又称之为GOF23
我们在学习设计模式的其实本质都是面向对象的设计的原则的实际应用，针对他不同的特性及其方式；独特的思维进行深入的了解和理解；实际的运用到我们的开发过程当中 ；
针对设计模式基本要素我们可以简单针对以下几个名词进行分析下：
模式的名称：每种设计独有的名称（根据模式的特点，解决方案，功能，名称等特征来命名；有效帮助大家记忆模式及其他的特点）
问题：这个模式的诞生解决了什么问题？什么时候去应用此设计模式
解决方案：解决这个问题诞生的一种方案，他是一种抽象的思维（提供设计问题的抽象描述），他并没有特定的含义，他的出发点是利用此种特性去解决去解决不同设计模式所应对的问题；
效果：他的效果，也可以理解为优缺点（或者时间空间的复杂程度）
💙 GOF 23🧡（设计模式介绍）
一种思维，一种态度，一种进步设计模式分为以下三大类：
创建型模式，共五种：
{描述如何去创建对象，目的是为使创建和使用进行分离才有了一下物种模式}
单例模式、工厂模式、抽象工厂模式、、建造者模式、原型模式
结构型模式，共七种：
{描述如何使用对象或者类组合成一些更大的结构类型的一些模式}
适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：
{描述类或对象如何相互协作完成一项行为（实现一个功能）}
策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
💛设计模式OOP七大原则
总原则－开闭原则
：对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。
里氏替换原则（Liskov Substitution Principle）
：继承必须确保超类所拥有的性质在子类中仍然成立；
任何基类可以出现的地方，子类一定可以出现。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它，我们可以尽可能去创建新的方法完成新的方法。（如果我们使用父类的方法去重载重写的话程序是容易出错的）
依赖倒转原则（Dependence Inversion Principle）
：面向接口编程，不要面向实现编程；
面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。降低耦合（使用接口或者抽象类我们更好的去指定起源不设计具体的操作没具体的细节交给具体的类去实现）
单一职责原则
：控制类的粒度的大小，将对象解耦，提高其内聚性；
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，否则就应该把类拆分。（控制他的粒子的力度，粒子越大说明他做的事情越多，我们尽可能去控制他的原子性，一个类只做一件事）
接口隔离原则（Interface Segregation Principle）
：要为各个类建立他们需要的专用接口；
每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。（建立他们专用的接口）
迪米特法则（最少知道原则）（Demeter Principle）
：只与你的直接朋友进行交谈，不跟陌生人说话；
一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
这边简单举例说明下：比如现在有A，B, C 3个同学：
A同学可以直接和B同学进行交谈，B同学也可以直接和C同学进行交谈；
但A同学不要直接和C同学交谈，哪怕叫B同学帮忙转发一下；
总结就是：只与你的直接朋友进行交谈，不跟陌生人说话；
弊端：会增加系统的一些复杂性；根据业务自行抉择；
合成复用原则（Composite Reuse Principle）
：尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承来实现；
尽量首先使用合成/聚合的方式，而不是使用继承。
23中设计模式都会依赖于七大原则；