Java设计模式

一、UML类图及时序图入门

1.1、UML的定义

1. 统一建模语言（英语：Unified Modeling Language,缩写UML）。
2. 非专利的第三代建模和规约语言。

1.2、UML特点

1. UML是一种开放的方法。
2. 用户说明、可视化、构建和编写一个正在开发的面向对象的、软件密集系统的制品的开放方法。
3. UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。

1.3、UML2.2分类

UML2.2中一共定义了14种图示，分类如下：

1、结构式图形：强调的是系统式的建模。

• 静态图（类图，对象图，包图）
• 实现图（组件图，部署图）
• 剖面图
• 复合结构图

2、行为式图形：强调系统模型中触发的事件。

• 活动图
• 状态图
• 用例图

3、交互式图形：属于行为式图形子集合，强调系统模型中资料程序。

• 通信图
• 交互概述图（UML2.0）
• 时序图（UML2.0）
• 时间图（UML2.0）

1.4、记忆技巧

1.4.1、记忆技巧-通用

• UML箭头方向：从子类指向父类。
• 提示：可能会认为子类是以父类为基础的，箭头应从父类指向子类（错误的观点）

1.4.2、记忆技巧-箭头方向

• 定义子类时需要通过extends关键字指定父类。
• 子类一定是知道父类定义的，但父类并不知道子类的定义。
• 只有知道对方信息时才能指向对方。
• 所以箭头方向是从子类指向父类的。

1.4.3、记忆技巧-实线与虚线

• 空心三角箭头：继承或实现
• 实线表示继承，is a 关系，扩展目的，不虚，很结实。
• 虚线表示实现，虚线代表“虚”无实体。
• 实线表示关联关系：关系稳定，实打实的关系，铁哥们。表示一个类对象和另一个类对象有关联，通常是一个类中有另一个类对象作为属性。
• 虚线表示依赖关系：临时用一下，若即若离，虚无缥缈，若有若无。表示一种使用关系，一个类需要借助另一个类来实现功能，一般是一个类使用另一个类作为参数使用，或作为返回值。

1.4.4、记忆技巧-空心菱形和实心菱形

• 菱形就是一个盛东西的器皿（例如盘子）。
• 聚合：代表空器皿里可以放很多相同东西，聚在一起（箭头方向所指的类）。整体和局部的关系，两者有着独立的生命周期，是has a的关系。弱关系，简称弱-空。
• 组合：代表满器皿里已经有实体结构的存在，生死与共。整体与局部的关系，和聚合相比，关系更加强烈，两者有相同的生命周期，contains-a的关系。强关系，简称强-满。
• 常见的数字表达及含义，假设有A类和B类，数字标记在A类侧。0..1表示0或1个实例；0..*表示0或多个实例；1..1表示1个实例；1表示只能有1个实例；1..*表示至少有1个实例；

1.5、UML类图

• Class Diagram:用于表示类、接口、实例等之间相互的静态关系。
• 虽然名字叫类图，但类图中并不只有类
• +表示public；-表示private；#表示protected；～表示default；有下划线的表示静态，斜体表示是抽象类或者抽象方法。

1.6、UML时序图

• Sequence Diagram:是显示对象之间交互的图，这些对象是按时间顺序排列的。
• 时序图中包括的建模元素主要有对象（Actor）、生命线（Lifeline）、控制焦点（Focus of control）、消息（Message）等

二、设计原则

2.1、开闭原则

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

优点：提高软件系统的可复用性及可维护性。

备注：源码见demo1包

2.2、依赖倒置原则

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象；针对接口编程，不要针对实现编程。

优点：可以减少类间的耦合性，提高系统的稳定性，提高代码可读性和可维护性，可降低修改程序所造成的风险。

备注：源码见demo2包

2.3、单一职责原则

定义：不要存在多于一个导致类变更的原因。一个类/接口/方法只负责一项职责。

优点：降低类的复杂度，提高类的可读性，提高系统的可维护性、降低变更引起的风险。

备注：源码见demo3包

2.4、接口隔离原则

定义：用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口，一个类对一个类的依赖应该建立在最小的接口上。建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。注意适度原则，一定要适度。

优点：符合我们常说的高内聚、低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。

备注：源码见demo4包

2.5、迪米特法则（最少知道原则）

定义：一个对象应该对其他对象保持最少的了解。又叫最少知道原则，尽量降低类与类的耦合。强调只和朋友交流，不和陌生人说话。朋友指的是出现在成员变量，方法的输入，输出参数中的类成为成员朋友类，而出现在方法体内部的类不属于朋友类。

优点：降低类之间的耦合。

备注：源码见demo5包

2.6、里氏替换原则

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低， 增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。问题提出：在编程中，如何正确的使用继承? => 里氏替换原则

定义：里氏替换原则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的以为姓里的女士提出的。如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法，里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，里氏替换原则是继承复用的基石，是开闭原则的补充。

优点：子类可以扩展父类的功能，但是不能修改父类原有的功能，子类可以实现父类的抽象方法，但是不能覆盖原有父类的方法，子类可以增加自己特有的方法，对子类的继承关系进行约束，是开闭原则的补充，可以增加程序的健壮性

备注：源码见demo6包

2.7、合成/复用原则（组合/复制原则）

定义：尽量使用对象组合，聚合的方式，而不是使用继承关系达到软件复用的目的。

优点：可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。

备注：源码见demo7包

三、设计模式

3.1、工厂模式

3.1.1、简单工厂 

定义：由一个工厂对象决定创建出哪一种产品类的实例。

类型：创建型，但不属于GOF23种设计模式。

使用场景：工厂类负责创建的对象比较少。客户端（应用层）只知道传入工厂类的参数对于如何创建对象（逻辑）不关心。

优点：只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。

缺点：工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，违背开闭原则。

备注：源码见demo8包