设计模式七大原则、类与类之间的关系和类图的简单绘制

本文主要整理一下设计模式七大原则，类图的绘制跟类与类之间的关系

设计模式

设计模式是一套反复使用的、多数人知晓的、经过分类编目的代码设计经验。

著名的就是GoF的23种设计模式

设计模式七大原则

开闭原则

一个软件实体应该对扩展开放，对修改关闭。
即实现在不修改源代码的情况下改变这个模块的行为。

单一职责原则

一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。

里氏代换原则

定义1：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。

定义2：所有引用基类的地方必须能透明的使用其子类的对象。将父类对象替换为子类对象时，程序的行为并不会发生改变，只是有可能表现不同（java多态）。

依赖倒转原则

高层模块不应该依赖底层模块，它们都应该依赖抽象。
抽象不应该依赖细节，细节应该依赖于抽象。

针对接口编程，不要针对实现编程

接口隔离原则

客户端不应该依赖那些它不需要的接口。（注：在该定义中的接口指的是所定义的方法）

又：一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。

合成/复用原则

尽量使用组合对象，而不是继承来达到复用目的。

迪米特法则

多种定义：
1）不要和“陌生人”说话。
2）直与你的直接朋友通信。
3）每一个软件单位对其他的单位都只有最少的知识。

简单的说，迪米特法则就是指一个软件实体应当尽可能少的与其它实体发生作用。

类之间的关系

• 关联关系（包括组合关系、聚合关系、单向关联、双向关联、自关联等）
• 依赖关系
• 泛化关系（继承）
• 实现关系

关联关系

表示一类对象与另一类对象之间有联系，通常将一个类的对象作为一个另一个类的属性
1）单向关联
用带箭头的实线表示
如顾客（Customer）拥有地址（Address）
2）双向关联
就是一条直线
如顾客（Customer）与商品（Product）之间相互关联

3）自关联
如链表的节点类型

聚合关系-构造方法或setter赋值

是关联关系的一种，也表示类与类之间有联系

在聚合关系中，成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。

一般是通过构造方法或者setter方法设置

比如
Test关联了String的一个实例s，并不对s进行new操作

class Test{
     
	String s;
	Test(String s) {
     
		this.s = s;
	}
	public void setS(String s) {
     
		this.s = s;
	}
}

在UML中，聚合关系用带空心菱形的直线表示

组合关系-new操作赋值

类与类之间有联系

组合关系也表示整体、部分关系，但是组合关系中部分和整体具有统一的生命期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间有着共同生死的关系。

在组合关系中，成员类是整体类的一部分，而且整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。

组合关系，两个类的联系，一个类通过new操作引用另一个类的实例

class Test{
     
	String s;
	Test(String s) {
     
		s = new String();
	}
}

在UML中，聚合关系用实心的菱形直线表示

依赖关系

依赖关系跟组合、聚合关系的不同是，组合、聚合所依赖的对象s是没有在堆上开辟空间的，需要Test端程序自行为s提供一个引用。

依赖关系，在某个方法中传来的对象是有它的地址引用的。

大多数情况下，依赖关系体现在某个类（如Test）的方法使用另一个的类（如Fun）的对象作为参数时。
如果一个类调用了另一个类的静态方法，或者在该类的方法中定义了另一个类的对象作为局部变量时，也是依赖关系的一种体现。

class Test{
     
	public void fun(Fun fun) {
     
		fun.run();
	}
}

在UML中，依赖关系用带箭头的虚线表示，由依赖一方指向被依赖一方。

泛化关系-继承关系

实现关系-实现接口

类图

解释一下"+"、"-"、"#"、"*"
+：public
-：private
#：protected
*：包内可见性（默认）