设计模式的产生背景：
“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。直到 1990 年，软件工程界才开始研讨设计模式的话题。1995年，“四人组”（Gang of Four，GoF）合作出版了《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）一书，在书籍中收录了 23 个设计模式，这是设计模式领域里程碑的事件，导致了软件设计模式的突破。直到今天，狭义的设计模式还是该书中所介绍的23种经典设计模式。
设计模式的概念：
软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
一、设计模式的六大设计原则1.开闭原则：Open Closed Principle，OCP
1）概念
开闭原则由勃兰特·梅耶（Bertrand Meyer）1988 年的著作《面向对象软件构造》提出。
简单意思指：程序软件实体要通过扩展的方式去增强，而不是通过修改原有的结构代码！
软件实体包括几个部分：项目中划分出的模块，类与接口，方法
2）例子
例如：在一个书店的价格展示中，现在遇到了打折的需求，可以解决的方法有：（1）修改接口（2）修改实体类（3）添加一个子类继承原方法修改getPrice()方法，依据开闭原则应选择方案（3），现实中也不难发现完成业务变化对系统的最小开发。这样修改也少，风险也小。
3）开闭原则的作用
开闭原则是面向对象程序设计的终极目标，使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。
具体来说：
（1）对软件测试的影响：软件测试时只需要对扩展的代码进行测试，原有的测试代码仍然能够正常运行。
（2）可以提高代码的可复用性：粒度越小，被复用的可能性就越大；原子和抽象编程可以提高代码的可复用性。
（3）可以提高软件的可维护性：稳定性高和延续性强，从而易于扩展和维护。
2.单一职责原则：Single responsibility principle，SRP
1）定义
单一职责原则又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。
简意：一个对象不应承受过多的职责，一个对象（类）只可以有一个原因去改变他（否则拆分）。
注意：具体使用要根据实际情况进行控制，根据场景而定义使用，有时也会为了效率而牺牲一些原则（原则是死的人是活的）！
2）例子
例如：打电话通信的过程功能，一个Phone类既包含拨通、挂断、数据处理。相当于负责了（1）协议管理（2）数据传送两个职责功能。这样做会导致当该类职责变化时削弱其特职责且代码冗余浪费。所以应当按照职责进行划分重组。
3）优劣
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。
优点：
降低类的复杂度其逻辑肯定要比负责多项职责简单得多、提高类的可读性、提高系统的可维护性、变更引起的风险降低变更功能可以显著降低对其他功能的影响。
3.里氏替换原则：Liskov Substitution Principle，LSP
1）优缺点
这是一个爱恨纠葛的父子关系的故事。该原则可以理解为：子类可以替换父类。
优点：
1. 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
2. 提高代码的重用性；
3. 提高代码的可扩展性，子类可形似于父类，但异于父类，保留了自己独特的个性；其实很多开源框架的扩展都是通过继承父类实现的。
4.提供产品或者项目的开放性。
缺点：
1. 继承是侵入性的，只要继承就必须拥有父类的所有方法和属性；
2. 降低了代码的灵活性。子类必须拥有父类的属性和方法，让子类中多了约束
3. 增加了耦合，当父类的常量、变量或者方法被修改了，需要考虑子类的修改，所以一旦父类有了变动，很可能会造成非常糟糕的结果，要重构大量的代码。
2）里氏替换原则的定义（例子见资料）
1. 子类必须完全实现父类的方法。
2. 子类中可以增加自己特有的方法。
3. 当子类覆盖或实现父类的方法时，方法的输入参数（方法的形参）要比父类方法的输入参数更宽松。
4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
3）里氏替换原则的作用
1. 里氏替换原则是实现开闭原则的重要方式之一。
2. 它克服了继承中重写父类造成的可复用性变差的缺点。
3. 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
4.依赖倒置原则：Dependence Inversion Principle，DIP
1）依赖倒置原则的定义
依赖倒置原则的原始定义为:High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions。
其实里面包含了三层含义：
高层模块不应该依赖低层模块，两者都应该依赖其抽象、抽象不应该依赖细节、细节应该依赖抽象。
核心思想：要面向接口编程，不要面向实现编程。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。以抽象建立起来的架构更易于扩展和协调开发。
2）依赖倒置原则的作用
依赖倒置原则可以降低类间的耦合性。
依赖倒置原则可以提高系统的稳定性。
依赖倒置原则可以减少并行开发引起的风险。
依赖倒置原则可以提高代码的可读性和可维护性。
/**需求人开汽车。 *人和车并非同时创建开发，但可以先创建接口和抽象类进行开发测试！ *如果我们此时再新增一个低层模块，只修改业务场景类，也就是高层模块， *对其它低层模块不需要做任何修改，业务依然可以运行，把变更引起的风险扩散降到最低。 *///引入了JMock工具，根据抽象虚拟一个对象进行测试//（不了解该测试工具也没关系，以后有机会再了解）。
import org.jmock.Expectations;import org.jmock.Mockery;import org.jmock.integration.junit4.JUnit4Mockery;import junit.framework.TestCase;import org.junit.Test;public class DriverTest extends TestCase { Mockery context=new JUnit4Mockery(); @Test public void test1(){ final ICar car=context.mock(ICar.class); IDriver driver=new Driver(); context.checking(new Expectations(){{ oneOf(car).run();} }); driver.drive(car);}}3）依赖倒置原则的实现方法
1. 每个类尽量提供接口或抽象类，或者两者都具备。
2. 变量的声明类型尽量是接口或者是抽象类。
3. 任何类都不应该从具体类派生。
4. 尽量不要覆写基类的方法.
5. 使用继承时结合里氏替换原则。
5.接口隔离原则:Interface Segregation Principle，ISP
1)接口隔离原则的定义
2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上.
简意是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；
接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
2)接口隔离原则的优点
约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。
1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；（1）定义过小，则会造成接口数量过多，使设计复杂化；（2）定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
5. 能减少项目工程中的代码冗余。
3)接口隔离原则的实现方法
在具体应用接口隔离原则时，应该根据以下几个规则来衡量。
接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
6.迪米特法则：Law of Demeter，LoD
1）迪米特法则定义
迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学的一个名为迪米特的研究项目，由伊恩·荷兰（Ian Holland）提出，它要求一个对象应该对其他对象有最少的了解。
简意：类与类降低之间无关的耦合，对无关类之简知道的越少越好提供Public即可，最好定死，只用中介交流。
迪米特法则还有一个定义是：只与你的直接朋友交谈，不跟“陌生人”说话。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
两个对象之间耦合就是朋友关系，组合、依赖、聚合等等。包括以下几类：
(1) 当前对象本身（this）、(2)当前对象的方法参数（以参数形式传入到当前对象方法中的对象）、(3) 当前对象的成员对象、(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友、(5)当前对象所创建的对象
2）迪米特法则的优点
降低了类之间的耦合度，提高了模块的相对独立性。
由于亲合度降低，从而提高了类的可复用率和系统的扩展性。
注意：过都使用迪米特法则会造成过多的中介类，增加系统复杂性，降低模块之间通信的效率,权衡使用！
3）迪米特法则的实现方法
从迪米特法则的定义和特点可知，它强调以下两点：
（1）从依赖者的角度来说，只依赖应该依赖的对象。
（2）从被依赖者的角度说，只暴露应该暴露的方法。
运用迪米特法则时要注意以下 6 点。
（1） 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
（2）在类的结构设计上，尽量降低类成员的访问权限。
（3）在类的设计上，优先考虑将一个类设置成不变类。
（4）在对其他类的引用上，将引用其他对象的次数降到最低。
（5）不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
（6）谨慎使用序列化（Serializable）功能。
原文链接，会放置详细的笔记地址，欢迎来关注”己墨日志“成长每一天！
点击喜欢作者，鼓励一下(❤ ω ❤)
