当程序员说去「设计模式」时，你是否会一脸懵逼，到底什么是设计模式呢？
很多人应该听说过设计模式（Design pattern），又或多或少的看过或用过设计模式，但是实际用在开发过程中总有点心有余而力不足的感觉。那肯定是对设计模式的理解有少许偏差或者不够深入。先不谈某种具体的模式，先来看看什么是设计模式？
什么是设计模式？
设计模式是一套代码设计「 经验的总结 」。项目中「 合理的 」运用设计模式可以「 巧妙的解决很多问题 」。
经验的总结：抱着「代码虐我千百遍，我待代码如初恋」的心态，最终得出来的「套路」。
合理的：要对设计模式的使用场景有一定的认识后才使用，「不要滥用」。如：输出一句“hello world”，非要强行给加上各种模式。
问：“为什么”，答：“总感觉少了模式！”。
巧妙的解决了很多问题：被广泛应用的原因。
为什么要提倡“Design Pattern呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？
设计模式之六大原则
开闭原则（Open Close Principle）
1988年，勃兰特·梅耶（Bertrand Meyer）在他的著作《面向对象软件构造（Object Oriented Software Construction）》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension,but closed for modification”。
- 意思：软件模块应该对扩展开放，对修改关闭。
- 举例：在程序需要进行新增功能的时候，不能去修改原有的代码，而是新增代码，实现一个热插拔的效果（热插拔：灵活的去除或添加功能，不影响到原有的功能）。
- 目的：为了使程序的扩展性好，易于维护和升级。
里氏代换原则（Liskov Substitution Principle）
- 意思：里氏代换原则是继承复用的基石，只有当衍生类可以替换掉基类， 软件单位的功能不受到影响时 ，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
- 举例：球类，原本是一种体育用品，它的衍生类有篮球、足球、排球、羽毛球等等，如果衍生类替换了基类的原本方法，如把体育用品改成了食用品（那么软件单位的功能受到影响），就不符合里氏代换原则。
- 目的：对实现抽象化的具体步骤的规范。
依赖倒转原则（Dependence Inversion Principle）
- 意思：针对接口编程，而不是针对实现编程。
- 举例：以计算机系统为例,无论主板、CPU、内存、硬件都是在针对接口设计的，如果针对实现来设计，内存就要对应到针对某个品牌的主板，那么会出现换内存需要把主板也换掉的尴尬。
- 目的：降低模块间的耦合。
接口隔离原则（Interface Segregation Principle）
- 使用多个隔离的接口，比使用单个接口要好。
- 举例：比如：登录，注册时属于用户模块的两个接口，比写成一个接口好。
- 目的：提高程序设计灵活性。
迪米特法则（最少知道原则）（Demeter Principle）
1987年秋天由美国Northeastern University的Ian Holland提出，被UML的创始者之一[Booch]等普及。后来，因为在经典著作《 The Pragmatic Programmer》而广为人知。
- 意思：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
- 举例：一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。
- 目的：降低类之间的耦合，减少对其他类的依赖。
单一职责原则（ Single responsibility principle ）
该原则由罗伯特·C·马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中给出的。马丁表示此原则是基于 汤姆·狄马克 (Tom DeMarco)和Meilir Page-Jones的著作中的 内聚性 原则发展出的。
- 意思：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
- 举例：该原则意思简单到不需要举例！
- 目的：类的复杂性降低，可读性提高，可维护性提高。
刚入行的时候，在想什么样的代码是好代码？看到很多前辈的文字都说好的代码要符合「高内聚，低耦合」，但是我听到这样的解释，是这样的
而现在对设计模式有了一定程度上的学习，感觉懂了一些，小伙伴们你们学会了吗？
高内聚,低耦合？
- 内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系；
- 耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
