设计模式，六大基本原则

1. 策略模式

1.1 调用spring的工厂模式得到接口实现的策略模式
1.2 通过枚举实现工厂模式直接调用接口的策略模式
优点：

1、减少重复逻辑if-else嵌套

2、降低后期维护难度

3、提高代码可复用性

缺点：

1、策略如果很多的话，会造成策略类膨胀；

2、使用者必须清楚所有的策略类及其用途；

2.工厂模式

简单工厂模式

如果对于产品的分类和名称是确定的，数量是相对固定的，感觉上面策略模式链接使用的枚举类实现简单工厂模式最佳

优点：

一个调用者想创建某个对象，只需知道其名称即可

屏蔽具体行为实现，调用者只需关心产品接口，减轻调用者负担

拓展性高，如果想增加一个产品类，只需拓展一个工厂类即可

3.抽象工厂模式

抽象工厂模式

使用情况
抽象工厂用来解决相对复杂的问题，适用于一系列、大批量的对象生产；

多个厂家使用自己的工厂生产带有自家标识的不同产品，每个产品带有自己的功能

缺点：
当需要增加一个新的产品时，所有的工厂类都需要进行修改，不满足开闭原则

4.单例模式

七种单例模式
单例模式在系统设置全局的访问点，优化环共享资源访问，例如可以设计 一个单例类，负责所有数据表的映射处理

5.建造者模式

建造者模式

建造者模式的典型应用场景如下：

产品类非常复杂，不同的调度产生不同的结果时，使用建造者模式比较适合；

相同的组件或配件都可以装配到一个对象，但是产生的结果又不相同，可以使用建造者模式。

建造者模式 VS 工厂方法模式

建造者模式关注的是零件类型和装配顺序（工艺）同为创建型模式，注重点不同。另外工厂模式只有一个建造方法，而建造者模式有多个建造零部件的方法并且强调建造顺序，而工厂模式没有顺序的概念。

6.模板方法

模板模式的精髓是复用抽象类中的公共方法，重写抽象类中的基础（抽象）方法，选择性使用抽象类中的钩子（hook Method）方法。使用模板模式的关键是：子类可以置换掉父类的可变部分，但是子类却不可以改变模板方法所代表的顶级逻辑。

应用场景

多个子类有公共方法，并且逻辑基本相同时；

可以把重要的、复杂的、核心算法设计为模板方法，其他的相关细节功能则由各个子类实现；

重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数约束其行为。

7.访问者模式

一看就懂
文件修改访问者

特点

1.访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化

2.增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者

3.增加新的数据结构变得困难，会违背开闭原则，被访问者要添加就不要用访问者模式

8.适配器模式

适配器模式

系统需要复用现有类，而该类的接口不符合系统的需求，可以使用适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

多个组件功能类似，但接口不统一且可能会经常切换时，可使用适配器模式，使得客户端可以以统一的接口使用它们

9.装饰者模式

装饰者模式

使用场景：

1、需要扩展一个类的功能，或给一个类添加附加职责；
2、需要动态的给一个对象添加功能，这些功能可以再动态的撤销；
3、需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实；
4、当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸式增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

10 六大基本原则

基本原则

我们使用了开闭原则、里氏代换原则和依赖倒转原则，在大多数情况下，这三个设计原则会同时出现，开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段，它们相辅相成，相互补充，目标一致，只是分析问题时所站角度不同而已。

开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。

单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

迪米特法则：在现在流行的三层软件架构中的体现则是尽量少的跨层调用相关对象

迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。