程序员经常说的设计模式到底是什么？

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