【设计模式-1】UML和设计原则

说明：设计模式（Design Pattern）对于软件开发，简单来说，就是软件开发的套路，固定模板。在学习设计模式之前，需要首先学习UML（Unified Modeling Language，统一建模语言）和面向对象设计的七大原则。

UML

设计模式在代码开发之前，先需要使用设计图的方式表现出来，UML是生产设计图的语言，也就是模型语言。UML的结构有视图（View）、图（Diagram）、模型元素（Model Element）、通用机制（General Mechanism），这里不做过深的介绍，只介绍类图和类之间的关系。

类图（Class Diagram）

结构

一般来说，一个类由三个部分组成：类名、属性和方法。如下这个类图：

• 类名：Teacher；
• 属性：name（String）、age（int，默认值是0）、gender（String）；
• 方法：setAge(int age)、getName()；

其中，属性和方法前面的符号，分别表示可见性：公有（public）、私有（private）、受保护（protected）分别用“+”、“-”、“#”来表示，在Java中，还有一种包内可见性（package），使用“*”来表示。

对于属性，在属性类型后面加 “= xx”，表示此属性设置默认值为“xx”，表示方式如下：

可见性 名称：类型 [= 默认值]
1

对于方法，表示方式如下：

可见性 名称（[参数列表]）[：返回类型]
1

以上方括号中的部分，表示可有可无；

---

如果该类是一个接口，类图表示如下：

其他内容不变，类名上面加两个尖括号包裹的interface，也有在类名左上角使用一个类似圆形取卡针标志来表示的，如下：

---

类之间关系

类与类之间的关系，分为以下几种：

关联关系

关联，指类与类之间存在联系，可分为双向关联、单向关联、自关联、多重性关联、聚合和组合，如下：

---

---

---

---

如下，表示一个按钮（Button）只能属于一个表单（Form），是一对一的关系，而一个表单，可以有0个或多个按钮；

常见的多重性关系有：1…1（一对一）、0…* （0对多） 、1…*（1对多）、0…1（0对一）、m…n（多对多）；

---

例如，汽车（Car）与发动机（Engine），发动机是汽车的组成部分，可以独立于汽车存在，并不依赖于汽车；

---

例如，头（Head）与眼睛（Eye），眼睛是头的组成部分，但是眼睛不能单独出来，头没有了眼睛也就没有了；

依赖关系；

例如，驾驶员（Driver）与车（Car）的关系，驾驶员依赖于车，没有车就无法使用驾驶方法；

泛化关系；

泛化关系，就是继承关系，如下，学生类（Student）和教师类（Teacher）继承于人类（Person）；

实现关系；

实现关系，顾名思义，如下，船（Ship）与车（Car）实现于交通工具接口（Vehicle），并实现其移动方法（move）；

其他

实际上，UML的图远不止这些，还有用例图（Use Case Diagram）、对象图（Object Diagram）、包图（Package Diagram）等加上类图共13个，但是类图用的最多。

在我手边的《设计模式》（第二版，清华大学出版社，第5页，刘伟主编）中，作者引用了Martin Fowler著作中的一段话，“If someone were to come up to you in a dark alley and say, ‘Psst, wanna see a UML diagram?’ that diagram would probably be a class diagram.The majority of UML diagrams I see are class diagrams.”（“如果有人在黑暗的小巷中向你走来并对你说：'嘿，想不想看一张UML图？'那么这张图很有可能就是一张类图，我所见过的大部分的UML图都是类图”）

---

面向对象设计原则

面相对象设计原则，指在程序设计时遵循的规范，有以下七个：

单一职责原则（Single Responsibility Principle，SRP）

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

简单来说，就是一个类，应该只干一件事。例如在没有三层架构前，一个请求，从接收、分析、处理，都在一个类里完成，无论这个请求的哪一个环节发生了改变都需要修改代码，可维护性差，代码耦合高。

---

开闭原则（Open-Closed Principle，OCP）

开闭原则定义：一个软件实体应当对扩展开发，对修改关闭。

就是说，后面如果需要新增需求，可以在不修改源码的基础上，对系统扩展。举个例子，一个管理系统的界面，有许多的记录，许多筛选项，最开始记录的字段少，筛选项也少，后面字段越来越多，需要新增一些筛选条件。

不符合开闭原则的做法：对DTO对象不断地新增筛选项，name（姓名）、age（年龄）、createTime（创建时间）……；

符合开闭原则的做法：在DTO对象里定义一个Map对象conditions，用于接收前端传递的条件参数。这样无论后面新增多少个筛选条件，实体类都不需要修改，只需要在Mapper.xml里面新增筛选字段（conditions.字段名）的查询条件即可；

private Map<String, String> conditions;
1

---

里氏代换原则（Liskov Substitution Principle，LSP）

里氏代换原则可以通俗表述为：在软件中如果能够使用基类（父类）对象（的地方），那么一定能够使用其子类对象。

---

依赖倒转原则（Dependency Inversion Principle，DIP）

依赖倒转原则定义：高层模块不应该依赖底层模块，他们都应该依赖抽象。抽象不应该依赖细节，细节应该依赖于抽象。

---

接口隔离原则（Interface Segregation Principle，ISP）

接口隔离原则定义：客户端不应该依赖那些它不需要的接口。

就是说，对于接口应该尽可能细化，而不是把一堆接口放到到一个大接口里面。如接口A表示飞行，接口B表示跳跃，接口C表示鸣叫，虽然这三个特性麻雀完全符合，但是不能把这三个接口合并到一个接口D中，然后让麻雀来实现，而是应该隔离开，让具备某种能力的类实现指定的接口。

---

合成复用原则（Composite Reuse Principle，CRP）

合成复用原则定义：尽量使用对象组合，而不是继承来达到复用的目的。

简单来说，就是类之间的关系，少用继承，尽量使用接口实现或者依赖注入的方式。例如有一个面试题，如何解决ArrayList线程不安全的问题，我所知道的有以下5个方法：

（1）使用CopyOnWriteArrayList()；

（2）使用Collections.synchronizedList()；

（3）定义一个类MyArrayList，继承ArrayList，重写其方法，每个方法用synchronized修饰；

（4）定义一个类MyArrayList，类里面定义一个ArrayList，自定义List的增删改查方法，用synchronized修饰，方法里面调用ArrayList对应的方法；

（5）使用Vector；

重点是第三个、第四个方法的对比，前者是继承，需要重写父类的方法，后者是设值注入，调用ArrayList的方法，显然后者更加灵活。

---

迪米特法则（Law of Demeter，LoD）

迪米特法则，又称最少知识原则原则，简单来说，就是指一个软件实体应当尽可能少地与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少地影响其他的模块。

总结

本篇文章内容基本来自《设计模式》（第2版，清华大学出版社，刘伟主编）第1、2章