什么地方可以用到设计模式？
面向对象(OOP)=>功能模块[设计模式+算法(数据结构)]=>框架[使用多种设计模式]=>架构[服务器集群]
使用的好处
软件具有可扩展性（增加新功能）
很好的维护性（可读性、规范性）
复用性
为什么使用设计模式
目标：解耦（高内聚 、低耦合）; [模块内部逻辑关系非常紧密，模块与模块之间的关系非常的松散]
代码扩展性、重用性、可读性，站在巨人的肩上。
是一套被反复使用、多数人知晓的、经过分类编码目的、代码设计经验的总结。
使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
https://zhuanlan.zhihu.com/p/98781830
优点：1、降低应用程序之间耦合。
2、将多种判定分散到各个处理类中，程序更加清晰，各类职责更加明确。
缺点：1.会增加类的数量。
2.使系统的复杂性增加。
六大原则
| 设计模式原则名称 | 简单定义 |
|---|---|
| 开闭原则 | 一个软件实体应该(类、模块、函数)对扩展开放，对修改关闭 |
| 单一职责 | 一个类只负责一个功能领域中的相应职责 |
| 里氏替换 | 所有引用基类的地方必须能透明地使用其子类的对象； 反之未必可以=》子类可以扩展父类的功能，但不能改变父类的原有功能。 |
| 依赖倒置 | 依赖于抽象，不能依赖具体实现 |
| 迪米特原则（最少知识） | 一个软件实体应当尽可能少的与其他实体类发生相互作用 |
| 接口隔离 | 类之间的依赖关系应该建立在最小的接口上 |
1、开闭原则（Open Close Principle）
开闭原则就是说对*扩展开放，对修改关闭*。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，需要面向接口编程。
开闭原则是面向对象设计中最基础的设计原则
回想一下其他5项原则，恰恰是告诉我们用抽象构建框架，用实现扩展细节的注意事项而已：
单一职责原则告诉我们实现类要职责单一；
里氏替换原则告诉我们不要破坏继承体系；
依赖倒置原则告诉我们要面向接口编程；
接口隔离原则告诉我们在设计接口的时候要精简单一；
迪米特法则告诉我们要降低耦合。
而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科
继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
再次来理解里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：
子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。【注意区分重载和重写】
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
依赖的写法：构造函数、setter方法、接口
依赖倒置原则的核心思想是面向接口编程
就是要依赖于抽象，不要依赖于具体。实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。
通俗点说：要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
4、接口隔离原则（Interface Segregation Principle）
使用多个隔离的接口，比使用单个接口要好。本意降低类之间的耦合度，而设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
原定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少
5、迪米特法则（最少知道原则）（Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。
定义：一个对象应该对其他对象保持最少的了解。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。
迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。
耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
6、单一职责（Single responsibility Principle）：应该有且仅有一个原因引起类的变更。
合成复用原则（Composite Reuse Principle）：原则是尽量使用合成/聚合的方式，而不是使用继承。
个人感觉，单例、工厂、装饰者、观察者、代理模式使用的频率比较高；
参考：
设计模式 ：Java中常用的设计模式_java设计模式-CSDN博客