设计模式7大设计原则

设计模式常用的7大原则：

1、单一职责原则

2、接口隔离原则

3、依赖倒转(倒置)原则

4、里氏替换原则

5、开闭原则

6、迪米特法则

7、合成复用原则

设计模式是为了代码或者软件具有更好的1、重用性（相同功能的代码不用重复编写）；2、可读性（其他程序员可以理解）；3、可扩展性（增加新功能很方便）；4、可靠性（新功能对原功能没有影响）；5、代码出现高内聚，低耦合的特性；

单一职责原则：

介绍：一个类应该只负责一个职责，如果A类负责两个不同的职责：职责1和职责2，那么当职责1修改时，职责2可能受到干扰，因此，应该将A类粒度细分为A1和A2。

单一职责分为两种：类单一职责和方法单一职责。

类单一职责例子：

方法单一职责例子：

单一职责原则注意事项和细节：

1、降低了类的复杂度；

2、提高了类的可读性，可维护性；

3、降低了变更引起的风险；

4、通常情况下应遵循单一职责原则，除非代码逻辑足够简单，才可以违反单一职责原则，只有类中方法足够少，才可以违反方法单一职责原则；

接口隔离原则：

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小接口之上。

为什么要用接口隔离原则？请看下面的例子：

依赖倒转原则：

依赖倒转原则是指：

1、高层模块不应该依赖于低层模块，二者都应该依赖其抽象；

2、抽象不应该依赖于细节，应该细节依赖于抽象；

3、依赖倒转原则的中心思想是面向接口编程；

4、依赖倒转原则基于这样的设计理念：相对于多变的细节，抽象则稳定的多。以抽象为基础搭建的架构，比以细节为基础搭建的架构要稳定的多。在java中，抽象指的是接口或者抽象类。细节是指具体的实现类。

5、使用接口或者抽象类的目的是为了制定好规范，而不涉及具体的操作，把展现细节的任务交给实现类去完成。

依赖关系传递的三种方式和应用案例：

1、接口传递

2、构造方法传递

3、set方法传递。

里氏替换原则：

OO中的继承性思考和说明：

1）继承包含了这一层含义：父类中已经实现好了的方法，实际上是在设定规范和契约，虽然它不强制它的子类必须遵守这些契约，但是如果子类对这些已经实现了的方法任意修改，则会对它的继承性造成一定破坏。

2）继承在给程序设计带来便利的同时，也带来了一定的弊端，比如使用继承会给程序带来一定的侵入性。程序的可移植性降低，增加了对象之间的耦合性，如果一个类被其他的类继承，则这个类修改的同时也得考虑其他子类。并且父类修改后，可能给子类带来故障。

3）问题提出：在编程中如何合理的使用继承？==》里氏替换原则（子类继承父类，最好不要重写父类方法）

基本介绍：

1、里氏替换原则（Lis Substitution Principle）在1988年，由麻省理工学院的以姓里的女士（这位女士还获得了2008年的图灵奖）提出的。

2、对每个类型为T1的对象o1，都有类型为T2的对象o2，使得T1定义的所有程序p在所有的对象o1都代换成o2时，程序p的行为没有发生任何变化，那么类型T2为类型T1的子类型。换句话说：所有引用基类的地方必须的透明的使用子类型。

3、在使用继承时，遵循里氏替换原则，在子类中最好不要重写父类的方法。

4、里氏替换原则原则告诉我们实际上两个类的耦合性增强了，在适当的情况下可以通过聚合、组合、依赖来解决问题。或者也可以将类中公共的方法提取出来成为一个公共接口，让其他类也实现这个公共接口。

改进方案：

开闭原则：

1）开闭原则（Open Closed Principle）是编程中最基础、最重要的原则

2）一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。用抽象构建框架，用实现扩展细节。

3）当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改原来的代码来实现变化。

4）编程中使用其他原则，以及使用设计模式的目的就是遵循开闭原则。

下图是非人类使用方法：

这种方法最大的问题是如果添加类的修改代码。

改进方案：

这样新增一个类就无需修改使用方代码。

迪米特法则：

1）一个对象应该对其他的对象保持最少的了解。

2）类与类关系越密切，耦合度越大。

3）迪米特法则（Demeter Principle）也叫最少知道原则，即一个类应该对自己依赖的类知道的越少越好。

也就是说对被依赖的类不管多复杂，都应该将逻辑封装在类的内部，对外除了提供public的方法外，不对外泄露任何信息。

4）迪米特法则还有个更简单的定义：只与直接朋友通信。

5）直接朋友：每个对象都与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说对象之间是朋友关系。耦合的方式有很多，其中包括：关联、泛化、实现、依赖、聚合、耦合（下一章节要讲）等等。其中，我们称出现在成员变量、方法参数、方法中的变量、方法返回值的类为直接朋友，而出现在局部变量中的类不是直接的朋友。也就是说陌生的类最好还是不要以局部变量的方式出现在类的内部。

迪米特法则的需要注意事项和细节：

1）迪米特法则的核心思想时降低类和类之间的耦合

2）但要注意：由于每个类都减少不必要的依赖，因此迪米特法则只是要求降低类间（对象）间的耦合关系，并不是要求完全没有依赖关系。

合成复用原则：

尽量使用合成/聚合的方式，少用继承。

设计模式的核心思想：

1）找出应用中可能变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。

2）针对接口编程，而不是针对实现细节编程。

3）为了实现交互对象之间的松耦合而努力。

UML图：

1）uml--unified modeling language UML(统一建模语言)是一种用于软件分析和设计的语言工具。它用于帮助软件开发人员进行思考和记录的结果。

2）uml本身是一套符号化的规定，就像数学符号和化学符号一样，这些词符号用于描述软件模型中的各个元素和他们之间的关系，比如类、接口、实现、依赖、组合、聚合等。如下图：

使用UML来建模，常用的工具有：Rational rose、亿图图示（国产），idea插件有plaintUML,eclipse AmaterasUML。

画UML图

划UML图和写文章差不多，目的都是让别人看，关键在于思路和条理清晰，UML分类：

1）用例图（USER CASE）

2）静态结构图：类图、包图、对象图、组件图、部署图；

3）动态行为图：交互图（时序图和协作图）、状态图、活动图;

说明：

1）类图是描述类和类之间的关系的，是UML图最核心的。

2）在讲解UML类图设计模式时，我们必然会使用到类图，为了能够让学员把设计模式学要到位，需要先给大家讲解类图。

uml类图：

1）类图是用于描述系统中的类本身的组成和类对象之间的静态关系。

2）类之间的关系：依赖、泛化、实现、关联、组合和聚合。

类和类中的关系

依赖：

只要在类中使用到了对方，我们就说他们之间存在存在依赖关系。如果没有对方，可能连编译都通过不了。

泛化：

泛化是依赖关系的特例。泛化就是继承。

实现：

实现是依赖关系的特例。A类实现了B接口或者抽象类，我们就说A和B之间是实现关系。

关联：

关联关系实际上是类与类之间的关联关系，它是依赖关系的特例，具有导向性，即双向关系和单向关系；

关联关系具有多重性，如'1'（表示有且只有一个）,'0......'（表示0个或多个）,'0,1'（表示0个或1个），'n...m'(表示从n个到m个都可以)，'m...'(表示至少m个)

单向一对一关系：

双向的1对1关系：

聚合：

聚合表示的是整体和部分的关系，整体和部分可以分开，聚合关系是关联关系的特例。所以他们具有关联关系的导航性和多重性。如一个学生有一个学号组成，学生和学号是可以分开的。使用带空菱形的实线来表示。

如果我们认为学生和学号是分不开的，则升级为组合关系。

组合：

组合也是表示的是整体和部分的关系，整体和部分不可以分开，组合关系也是关联关系的特例。所以他们具有关联关系的导航性和多重性。如一个人Persion有一个头部Head组成，人和头部是不可以分开的。使用黑色菱形的实线来表示。

设计模式三大类：

设计模式分为3大类，共23种

1）创建型模式：单例模式、工厂模式、抽象工厂模式、原型模式、建造者模式；

2）结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式；

3）行为模式：模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、责任链模式（职责链模式）；