学习设计模式的目的：
代码重用性可读性可扩展性可靠性使程序呈现高内聚，低耦合的特性
设计模式七大原则
1.单一职责原则
对类来说，即一个类只负责一项职责。
假如类A负责2个不同的职责：职责1和职责2，当职责1因为需求而发生改变时，可能造成职责2执行错误。所以需要将类A的粒度分解为A1，A2。
1.1 注意事项和细节
降低类的复杂度，一个类只负责一项职责提高类的可读性，可维护性降低变更引起的分线通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。
1.2 举例：
public class DanYiZhiZeTest1 {
public static void main(String
[] args
) {
Vehicle vehicle
= new Vehicle();
vehicle
.run("摩托车");
vehicle
.run("汽车");
vehicle
.run("飞机");
}
}
class Vehicle {
public void run(String vehicle
) {
System
.out
.println(vehicle
+ "在公路上运行。。。");
}
}
结果：
解决方法1：
将类拆分为公路交通工具类和天空交通工具类
但是这样容易造成类冗余，同时会大量修改客户端代码，也会造成堆空间对象大量增加
解决方法2：
将run方法拆分为run和runAir方法：
class Vehicle2 {
public void run(String vehicle
) {
System
.out
.println(vehicle
+ "在公路上运行。。。");
}
public void runAir(String vehicle
) {
System
.out
.println(vehicle
+ "在天空运行。。。");
}
}
2.接口隔离原则
2.1 基本介绍
客户端不应该依赖它不需要的接口，即一个类对另一个类的以来应该建立在最小的接口上也称接口最小化原则，强调的是一个接口拥有的行为应该尽可能的小
如果我们不满足接口隔离原则，经常会出现：我们实现了一个接口，但是这个接口中很多方法我们不需要使用，有很多空实现。这样做不仅会导致代码冗余，还会给别人一个错觉，我们这个类拥有这个方法，但实际上里面没有任何实现。
举例：
假如我们新建了一个老年机对象，我们还需要实现其中的play方法，但是老年机显然是不能够玩游戏的
interface phone {
void call();
void play();
}
改进：
interface phone {
void call();
}
interface smartPhone extends phone {
void play();
}
3.依赖倒转原则
3.1 基本介绍
高层模块不应该依赖底层模块，二者都应该以来其抽象抽象不应该依赖细节，细节应该依赖抽象依赖倒转的中心思想是面向接口编程依赖倒转原则是基于这样的设计理念：相对于细节的对变形，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类。使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
3.2 举例：
情况一：
分析： 1.比较简单实现 2.如果我们信息来源是微信，短信，这样就需要修改我们的Person类
public class DependecyInversion {
public static void main(String
[] args
) {
Person person
= new Person();
person
.receive(new Email());
}
}
class Email {
public String
getInfo() {
return "电子邮件 ： hello";
}
}
class Person {
public void receive(Email email
) {
email
.getInfo();
}
}
情况二： 改进，添加一个接收接口，让电子邮件，微信，短信实现这个接口。 使用接口传递。
public class DependecyInversion2 {
public static void main(String
[] args
) {
Person2 person
= new Person2();
person
.receive(new Email2());
}
}
interface IReceiver {
String
getInfo();
}
class Email2 implements IReceiver {
public String
getInfo() {
return "电子邮件 ： hello";
}
}
class WeChat implements IReceiver {
public String
getInfo() {
return "微信 ： hello";
}
}
class Person2 {
public void receive(IReceiver iReceiver
) {
iReceiver
.getInfo();
}
}
3.3 依赖传递的三种方式：
通过接口传递通过构造器通过setter方法
3.4 依赖倒转原则的注意事项和细节
底层模块尽量都是抽象类或接口，或者两者都有，程序稳定性更好变量的声明类型尽量使抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化继承时遵循里氏替换原则
4.里氏替换原则
4.1 OO的继承性的思考和说明
继承包含这样一层含义：父类中凡事已经实现好的方法，实际上实在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些七月，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障
4.2 基本介绍
里氏替换原则：如果对每个类型为T1的对象o1，都有类型为T2 的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换为o2时，程序P的行为没有发生变化，那么类型T是类型T1的子类型。换句话说：一个子类应该可以替换掉父类并且可以正常工作。在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。继承实际上让2个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。
5.开闭原则
一个软件实体如类、模块、函数应该：对扩展开放（对提供方），对修改关闭（对使用方）；用抽象构建矿建，用实现扩展细节。当软件需要变化是，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有代码来实现变化
6.迪米特法则（最小知道原则）
基本介绍：
一个对象应该对其他对象保持最少的了解类与类的关系越密切，耦合度越大迪米特法则又叫最小知道原则，即一个类对自己以来的类知道的越少越好。也就是说，对于被依赖的类不管多复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不泄露任何信息。应该尽可能将一个类的细节全部写在这个类的内部，不要漏出来给其他类知道，否则其他类就很容易会依赖于这些细节，这样类之间的耦合度就会急速上升，这样做的后果往往是一个类随便改点东西，依赖于它的类全部都要改简单点说：降低类的耦合，只对外公布（public）必须要公布的。
7.合成复用原则
尽量使用合成/聚合的方式，而不是使用继承。
比如让B类使用A类的方法，如果我们使用继承的方式，这样我们增加了A类与B类的耦合。 我们可以在B中创建A的对象来使用。
设计原则核心思想
找出代码中可能会变化的部分，把他们独立出来，不要和那些不需要变化的代码混合在一起针对接口变成，而不是针对实现编程为了交互对象之间的松耦合设计而努力
