在上一篇文章中，针对接口鉴权的开发，我们讲了如何进行面向对象分析（OOA），也就是需求分析。实际山，需求定义清楚之后，这个问题就已经解决了一大半，这也是为什么要画那么多篇幅来讲解需求分析。今天，我们再来看一下，针对面向对象分析产出的需求，如何来进行面向对象设计（OOD）和面向对象编程（OOP）。
如何进行面向对象设计？
我们知道，面向对象分析的产出是详细的需求描述，那面向对象设计的产出就是类。在面对对象设计环节，我们将需求描述转化为具体的类的设计。我们把这一设计环节拆解细化一下，主要包含一些几个部分：
- 划分职责进而识别出有哪些类；
- 定义类及其属性和方法；
- 定义类与类之间的交互关系；
- 将类组装起来并提供执行入口。
实话讲，不管是面向对象分析还是面向对象设计，理论的东西都不多，所以我们还是结合鉴权这个例子，在实战中体会如何做面向对象设计。
1.划分职责进而识别出有哪些类
在面向对象有关书籍中经常提到，类是现实世界中事物的一个建模。但是，并不是每个需求都能映射到现实世界，也并不是每个类都与现实世界中的事物一一对应。对于一些抽象的概念，我们是无法通过映射现实世界中的事物的方式来定义类的。
所以，大多数讲面向对象的书籍中，还会讲到另外一种识别类的方法，那就是把需求描述中的名词罗列出来，作为可能的候选类，然后再进行筛选。对于没有经验的初学者来说，这个方法比较简单、明确，可以直接照着做。
不过，我个人更喜欢另外一种方法，那就是根据需求描述，把其中涉及的功能点，一个一个罗列出来，然后再去看哪些功能点职责相近，操作同样的属性，是否应该归为同一个类。我们来看一下，针对鉴权这个例子，具体该如何来做。
在上一篇文章中，我们已经给出了详细的需求描述，为了方便你查看，我把它重新贴在了下面。
- 调用方进行接口请求的时候，将URL、AppID、密码、时间戳拼接在一起，通过加密算法生成token，并且将token、AppID、时间戳拼接在URL中，一并发送到微服务端。
- 微服务端在接收到调用方的接口请求之后，从请求中拆解出token、AppID、时间戳。
- 微服务端首先检查传递过来的时间戳跟当前时间，是否在token失效时间窗口内。如果已经超过失效时间，那就算接口调用鉴权失败，拒绝接口调用请求。
- 如果token验证没有过期失效，微服务端再从自己的存储中，取出AppID对应的密码，通过同样的token生成算法，生成另外一个token，与调用方传递过来的token进行匹配。如果一致，则鉴权成功，允许接口调用；否则就拒绝接口调用。
首先，我们要做的是逐句阅读上面的需求描述，拆解成小的功能点，一条一条罗列下来。注意，拆解出来的每个功能点要尽可能的小。每个功能点只负责做一件很小的事情（专业叫法是“单一职责”，后面章节中我们会讲到）。下面是我逐句拆解上述需求描述之后，得到的功能点列表：
- 把URL、AppID、密码、时间戳拼接为一个字符串；
- 对字符串进行加密算法加密生成token；
- 将token、AppID、时间戳拼接到URL中，形成新的URL；
- 解析URL，得到token、AppID、时间戳等信息；
- 从存储中取出AppID和对应的密码；
- 根据时间戳判断token是否过期失效;
- 验证两个token是否匹配；
从上面的功能列表中，我们发现，1、2、6、7都是跟token有关，负责token的生成、验证；3、4都是在处理URL，负责URL的拼接、解析；5是操作AppID和密码，负责从存储中读取AppID和密码。所以，我们可以粗略的得到三个核心的类：AuthToken、Url、CredentialStorage。AuthToken负责实现1、2、6、7这四个操作；Url负责3、4两个操作；CredentialStorage负责5这个操作。
当然，这是一个初步的类的划分，其他一些不重要的、边边角角的类，我们可能暂时没法一下想全，但这也没关系，面向对象分析、设计、编程本来就是一个循环迭代、不断优化的过程。根据需求，我们先给出一个粗糙版本的设计方案，然后基于这样一个基础，再去迭代优化，会更容易一些，思路也会更更加清晰一些。
不过，我还要再强调一点，接口调用鉴权这个开发需求比较简单，所以，需求对应的面向对象设计并不复杂，识别出来的类也并不多。但如果我们面对的是更加大型的软件开发、更加复杂的需求开发，涉及的功能点可能会很多，对应的类也会比较多，像刚刚那样根据需求逐句罗列功能点的方法，最后会得到一个长长的列表，就会有点凌乱、没有规律。针对这种复杂的需求开发，我们受邀作的时进行模块划分，将需求先简单划分成几个小的、独立的功能模块，然后再在模块内部，应用我们刚刚讲的方法，进行面向对象设计。而模块的划分和识别，跟类的划分和识别，是类似的套路。
2.定义类及其属性和方法
刚刚我们通过分析需求描述，识别出了三个核心的类，它们分别是AuthToken、Url和CredentialStorage。现在我们来看下，每个类都有哪些属性和方法。我们还是从功能点列表中挖掘。
AuthToken类相关的功能点有四个：
- 把URL、AppID、密码、时间戳拼接为一个字符串；
- 对字符串通过加密算法加密生成token；
- 根据时间戳判断token是否过期失效；
- 验证两个token是否匹配。
对于方法的识别，很多面向对象相关的数据，一般都是这么讲的，识别出需求描述中的动词，作为候选的方法，再进一步过滤筛选。类比一下方法的识别，我们可以把功能点中涉及的名词，作为候选属性，然后同样进行过滤筛选。
我们可以借用这个思路，根据功能点描述，识别出来AuthToken类的属性和方法，如下所示：
从上面的类图中，我们可以发现这样三个小细节。
- 第一个细节：并不是所有出现的名词都被定义为类的属性，比如URL、AppID、密码、时间戳这几个名词，我们把它作为了方法的参数。
- 第二个细节：我们还需要挖掘一些没有出现在功能点描述中属性，比如createTime，expireTimeInterval，它们用在isExpired()函数中，用来判定token是否过期。
- 第三个细节：我们还给AUthToken类添加了一个功能点描述中没有提到的方法getToken()。
第一个细节告诉我们，从业务模型上来说，不应该属于这个类的属性和方法，不应该被放到这个类里。比如URL、AppID这些信息，从业务模型上来说，不应该属于AuthToken，所以我们不应该放到这个类中。
第二、第三个细节告诉我们，在设计类具有哪些属性和方法的时候，不能单纯地依赖当下的需求，还要分析这个类从业务模型上来讲，理应具有哪些属性和方法。这样可以一方面保证类定义的完整性，另一方面不仅为当下的需求还为未来的需求做些准备。
Url类相关的功能点有两个：
- 将token、AppID、时间戳拼接到URL中，形成新的URL；
- 解析URL，得到token、AppID、时间戳等信息。
虽然需求描述中，我们都是以URL来代指接口请求，但是，接口请求并不一定是以URL的形式来表达，还有可能是Dubbo、RPC等其他形式。为了让这个类更加通用，命名更加贴切，我们接下来把它命名为ApiRequest。下面是我根据功能点描述设计的ApiRequest类。
CredentialStorage类相关的功能点有一个：
- 从存储中取出AppID和对应的密码。
CredentialStorage类非常简单，类图如下所示。为了做到抽象封装具体的存储方式，我们将CredentialStorage设计成了接口，基于接口而非具体的实现编程。
3.定义类与类之间的交互关系
类与类之间都有哪些交互关系呢？UML统一建模语言中定义了六种类之间的关系。它们分别是：泛化、实现、关联、聚合、组合、依赖。关系比较多，而且有些还比较相近，比如聚合和组合，接下来我就注意讲解一下。
泛化（Generalization）可以简单理解为继承关系。
实现（Realization）一般是指接口和实现类之间的关系。
聚合（Aggregation）是一种包含关系，A类对象包含B类对象，B类对象的声明周期可以不依赖A类对象的生命周期，也就是说可以单独销毁A类对象而不影响B对象，比如课程与学生之间的关系。
组合（Composition）也是一种包含关系。A类对象包含B类对象，B类对象的生命周期依赖A类对象的生命周期，B类对象不可单独存在，比如鸟与翅膀之间的关系。
关联（Association）是一种非常弱的关系，包含聚合、组合两种关系。具体到代码层面，如果B类对象是A类的成员变量，那B类和A类就是关联关系。
依赖（Dependency）是一种比关联关系更加弱的关系，包含关联关系。不管是B类对象是A类对象的成员变量，还是A类对象的方法使用B列对象作为参数或者返回值、局部变量，只要B类对象和A类对象有任何使用关系，我们都称它们有依赖关系。
我从更加贴近编程的角度，对类与类之间的关系做了调整，只保留了四个关系：泛化、实现、组合、依赖，这样你掌握起来会更加容易。
其中，泛化、实现、依赖的定义不变，组合关系替代UML中组合、聚合、关联三个概念，也就相当于重新命名关联关系为组合关系，并且不再区分UML中的组合和聚合两个概念。之所以这样重新命名，是为了跟我们前面讲的“多用组合少用继承”设计原则中的“组合”统一含义。只要B类对象是A类对象的成员变量，那我们就称，A类跟B类是组合关系。
理论的东西讲完了，让我们来看一下，刚刚我们定义的类之间都有哪些关系呢？因为目前只有三个核心的类，所以只用到了实现关系，也即CredentialStorage和MysqlCredentialStorage之间的关系。