什么是设计模式？ 设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。- 项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。
- 复用解决方案: 设计模式本身就是对某一类问题的通用解决方案，是更高级别的服用，已经超出了代码复用。
- 确定通用术语: 开发中的交流和协作都需要共同的词汇其础和对问题的共识. 当你有想表达却又表达不清楚的设计思路，即使表达出来也会被同事误解的时候，设计模式就显出沟通的优势了。
- 代码更易于修改与维护:因为设计模式都是久经考验的解决方案,它们的结构都是经过长期的发展形成的，善于应对变化，设计模式本身也是对变化点的封装。
- 模式有助于提高思考层次: 学习模式后,就算不用模式中的方法，也会更好的采取策略去解决问题。
- **单一职责 **:不要存在多于一个导致类变更的原因。通俗的说，即
一个类只负责一项职责
- 里氏替换原则:所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类可以扩展父类的功能，但不能改变父类原有的功能。类B继承类A时，除添加新的方法完成新增功能外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
- 依赖倒置原则: 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
一般会在项目框架的搭建的时候用到，例如，业务逻辑层相对于数据层是高层模块，因为业务逻辑层需要调用数据层去连接数据库，但是要做到可扩展高复用，尽量不要让业务逻辑层依赖数据层，可以在数据层抽象出一个接口，让业务逻辑层依赖于这个抽象接口。
- 接口隔离原则: 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
- 迪米特法则: 一个对象应该对其他对象保持最少的了解。
- 类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
- 简单的理解就是高内聚，一个类尽量减少对其他对象的依赖，并且这个类的方法和属性能用私有的就尽量私有化。
- 注意：
1. 只与直接的朋友通信，不要和陌生人说话。
2. 过分的使用该原则，将导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
- 开闭原则: 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
- 在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
- 当软件需求变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
