设计模式之基础

一、UML关系简单描述

UML关系有六种，分别是继承(又叫泛化)、实现、依赖、关联、聚合、组合，其相应的耦合度由强到弱依次是：继承 = 实现 > 组合 > 聚合 > 关联 > 依赖。

1、继承：继承是一种 is-a 的关系，，在java里用extends关键词来说明这种关系，uml中用一个实线加一个空心箭头表示这种关系。

2、实现：实现几乎和继承一样，但它是一种类与接口的关系，表示类是接口所有特征和行为的实现，用implements关键词表示，uml中使用空心三角加虚线来表示这种关系。

3、组合：组合描述的是整体与部分的关系，是一种 contains-a 的关系。其部分的生命周期与整体的生命周期一致，比如公司和部门，公司一旦倒闭，公司里的部门就会立即解散。Uml中用实心菱形与实线表示，可以加上箭头，也可以不加，同样还可以加上数量关系。

4、聚合：聚合描述的也是整体与部分的关系，但他是一种 has-a 的关系。其部分的生命周期和整体的生命周期并不一致，换句话说，整体与部分的生命周期是相互独立的，这也是聚合关系与组合关系的区别。比如小汽车和轮胎，不算备胎，一个小汽车有四个轮胎，当车子因为其他原因报废的时候，轮胎还是可以安在其他车子上使用的。Uml中用空心菱形和实线来表示，同样，可以加上箭头，也可以加上数量关系。

5、关联：关联关系一般用来定义对象之间静态的、天然的结构，是一种永久的绝非偶然的关系，所以，关联关系是一种“强关联”的关系。在代码中表现为，关联类引用了被关联类的一个属性，或者被关联类作为了关联类的一个属性。
举个例子，一个成熟的男性青年与精子，两者之间一定是一个永久的关系，绝非偶然。Uml中，用一根实线来表示关联关系，加上箭头就是单项关联，不加就是双向关联。

6、依赖：依赖关系一般解释为一个类使用了另一个类，这种关系是偶然性的，是临时性的，只有在运行时才会表现出来，那在代码中的体现是被依赖者
作为了依赖者的一个方法的输入或者输出参数，或者仅仅是一个局部变量，也或者是一个静态方法或属性的调用。比如Jack切西瓜，用什么切，用刀子切，那Jack和刀子就是一个依赖关系。Uml中用一根虚线加上箭头来表示。

二、六大设计原则简单介绍

1、单一职责原则：英文名称是Single Responsibility Principle,简称SRP。单一职责原则的定义是：应该有且仅有一个原因引起类的变更。单一职责原则提出了一个编写程序的标准，用职责或变化原因来衡量接口或者类设计的是否优良，但是职责和变化原因都是不可度量的，因项目而异，因环境而异。
2、里氏替换原则：英文名称是Liskov Substitution Principle,简称LSP。只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类，但是反过来就不行，有子类出现的地方，父类未必就能适应。编码时，在类中调用其他类时无比要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
3、依赖倒置原则：英文名称是Dependence Inversion Principle，简称DIP。DIP原则在Java语言中的体现是：

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的;
• 接口或者抽象类不依赖于实现类;
• 实现类依赖接口或者抽象类;

4、接口隔离原则：英文名称Interface Segregation Principle。有两种定义，第一种是“客户端不应该依赖他不需要的接口”，即客户端需要什么接口就提供什么接口，把不需要的接口剔除掉，那就需要对接口进行细化，保证接口的纯洁性;第二种定义是“类间的依赖关系应该建立在最小的接口上”，它要求是最小的接口，也要求接口细化。他和单一职责是有区别的，他俩的审视角度是不一样的，接口隔离原则要求接口的方法尽量少，而单一职责原则更注重类或者接口的职责的单一性。

5、迪米特原则：英文名称Law of Demeter,简称LoD，也称最小知识原则(Least Knowledge Principle，LKP)。含义是一个对象应该对其他对象有最少的了解，通俗讲一个类应该对自己需耦合或者调用的类知道的最少，你的内部实现是复杂还是不复杂跟我没关系，我只需要调用你给我的public方法。
6、开闭原则：英文名称是Open Closed Principle。含义是一个软件实体如类、模块和函数应该对拓展开放，对修改关闭。开闭原则是Java世界最基础的设计原则，上述5中原则都是开闭原则的具体形态，也就是说前五个原则就是指导设计的，而开闭原则才是精神领袖。在实际工作中，我们应该如何应用？

• 第一、抽象约束。通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或者抽象类中不存在的public方法;参数类型、引用类型尽量使用接口或者抽象类，而不是实现类;抽象曾尽量保持稳定，一旦确定即不允许修改。
• 第二、封装变化。将相同的变化封装到一个接口或者抽象类中，将不同的变化封装到不同的接口或者抽象类中，不应该有两个不同的变化出现在同一个接口或者抽象类中。