1 .设计模式的目的：
- 代码重用性（相同的代码不用重复编写）；
- 可读性（编码规范，便于其他程序员的阅读和理解）；
3.可扩展性（当需要增加新的功能时 非常方便）； - 可靠性（当我们增加新的功能时，会原来的功能没有影响）；
- 使程序呈现高内聚，低耦合的特性；
2. 设计模式原则：
其实就是程序员在编程时应当遵守的原则，也是各种设计模式的基础。
单一职责原则
接口隔离原则
依赖倒置原则
里氏替换原则
开闭原则
迪米特法则
合成复用原则
3、设计模式的7大原则：（开口合里最单一）
开闭原则：对扩展开放，对修改关闭
接口隔离原则(接口要小而专)
合成复用原则：（首选使用组合来实现复用，其次才考虑继承）
里氏代换原则：（任何时候都可以用子类型替换掉父类型。）
迪米特法则/最少知识原则（一个对象应当对其他对象有尽可能少的了解）
单一职责原则（一个类只负责一项职责）
依赖倒转原则：（设计要依赖于抽象而不是具体化）
1. 开闭原则：
软件实体应当对扩展开放，对修改关闭。
（在理想的状态下，当我们需要为一个软件系统增加新功能时，只需要从原来的系统派生出一些新类就可以，不需要修改原来的任何一行代码。要做到开闭有两个要点：①抽象是关键，一个系统中如果没有抽象类或接口系统就没有扩展点；②封装可变性，将系统中的各种可变因素封装到一个继承结构中，如果多个可变因素混杂在一起，系统将变得复杂而换乱，如果不清楚如何封装可变性，可以参考《设计模式精解》一书中对桥梁模式的讲解的章节。）
2. 接口隔离原则：
客户端不应该依赖它不需要的接口，即 一个类对另一个类的依赖应该建立在最小接口上。
比如：
一个接口interface有三个方法，分别是方法1，2，3 ， 类A依赖与接口中的方法1，2 ，类B依赖于接口中的方法2，3；此时 遵循接口隔离原则， 可以将接口interface 拆分成三个接口 分别为：
interface1(含方法1),interface2(含方法2),interface3(含方法3)
类A依赖与方法1，2，则让类A继承 interface1(含方法1),interface2(含方法2)两个接口；类B依赖与方法2，3，则让类A继承 nterface2(含方法2),interface3(含方法3),i两个接口；就是接口隔离原则的实现。
3. 合成/聚合原则：
尽量使用聚合或者组合 ，而不是用继承
类之间的关系主要有两种：组合关系和继承关系。
虽然它们都可以实现代码复用，但是相对于继承关系而言，组合关系可以使系统变得更加灵活，降低类与类之间的耦合度。如果一个类的变化对其他类造成的影响相对较少，一般首选使用组合来实现复用，其次才考虑继承。）
java继承的好处：
子类能直接继承父类的对象；
创建子类的对象时，无须创建父类的对象；
java继承的坏处：
使用继承会给程序带来侵入性， 程序的可移植性降低， 增加了对象的耦合性；
4.里氏替换原则：
1.里氏替换原则是在1988年，麻省理工学院的姓里女士提出的；
2 .所有引用基类的地方 必须透明的使用其子类的对象；
3.在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法；
- 里氏替换原则告诉我们， 继承实际上两个类的耦合性增强了， 在适当的情况下，让原来的父类和子类都继承一个更通俗的基类， 原来的基础关系去掉， 采用 依赖，聚合，组合等关系替换。
java继承的好处：
子类能直接继承父类的对象；
创建子类的对象时，无须创建父类的对象；
java继承的坏处：
使用继承会给程序带来侵入性， 程序的可移植性降低， 增加了对象的耦合性；
5 迪米特法则/最少知识原则，:
1.一个对象应该对其他对象保持最少的了解
- 类之间的关系越密切，耦合度越大
- 即一个类对自己依赖的类知道的越少越好
4.迪米特法则即只与直接朋友通信。
（出现的成员变量，方法参数，方法返回值即为直接朋友，而出现在局部变量中的类不是直接朋友）
迪米特法则是要求降低类之间的依赖，而不是要求类之间完全没有依赖关系
6. 单一职责原则：
一个类只负责一项职责（这样设计的出发点是担心如果一个类负责多项职责，担心其中一项职责的变化会影响此类下的其他项职责）
单一职责原则注意的事项和细节：
1.降低类的复杂度，一个类只负责 一项职责；
- 提高类的可读性，可维护性；
3.降低变更引起的风险； - 通常情况下，我们应担遵守单一职责原则， 只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类的方法数量足够少，可以在方法级保持单一职责原则；
7. 依赖倒转原则：
设计要依赖于抽象而不是具体化
（该原则说得直白和具体一些就是声明方法的参数类型、方法的返回类型、变量的引用类型时，尽可能使用抽象类型而不用具体类型，因为抽象类型可以被它的任何一个子类型所替代）
依赖倒置原则：
1.高层模块不应该依赖底层模块，二者都应该依赖其抽象；
2.抽象不应该依赖其细节，细节应该依赖其抽象；
3.依赖倒置原则的中心思想是面向接口编程；
4.依赖倒置原则是基于这样设计：相对于细节的多变性，抽象的东西要稳定的多;
- 使用接口或者抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
依赖传递的三种方式：
接口传递；
构造方法传递；
setter方法传递；
依赖倒置原则的注意事项和细节：
1.底层模块尽量都要有抽象类或者接口， 或者两者都有，程序稳定性更好；
- 变量的声明类型尽量是抽象类或者接口， 这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序的扩展和优化；
- 继承时遵循里氏替换原则
接口1
public interface Infomation {
public String Info();
}
接口2
基于测试类
