【设计模式之美】面向对象分析方法论与实现（二）：需求到接口实现的方法论

【设计模式之美】面向对象分析方法论与实现（一）：需求分析方法论 描述了如何进行需求描述，本文描述

根据示例需求，如何来进行面向对象设计（OOD）和面向对象编程（OOP）。

1. 描述怎么根据需求描述确定类：类封装了单个需求的逻辑，代表了能够处理这个需求的所有逻辑。
2. 定义类与类之间的关系
3. 拼装类实现鉴权逻辑

一. 进行面向对象设计

面向对象分析的产出是详细的需求描述，那面向对象设计的产出就是类。

在面向对象设计环节，我们将需求描述转化为具体的类的设计。我们把这一设计环节拆解细化一下，主要包含以下几个部分：

 

1. 划分职责=>需要有哪些类

根据需求描述，把其中涉及的功能点，一个一个罗列出来，然后再去看哪些功能点职责相近，操作同样的属性，是否应该归为同一个类。

需求描述重放

 

拆解需求

拆解出来的每个功能点要尽可能的小。每个功能点只负责做一件很小的事情，要符合“单一职责”。拆解需求后，得到的功能点列表：
 

 

• 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

我们可以发现这样三个小细节。

1. 并不是所有出现的名词都被定义为类的属性，比如 URL、AppID、密码、时间戳这几个名词，我们把它作为了方法的参数。
2. 需要挖掘一些没有出现在功能点描述中属性，比如 createTime，expireTimeInterval，它们用在 isExpired() 函数中，用来判定 token 是否过期。
3. 我们还给 AuthToken 类添加了一个功能点描述中没有提到的方法 getToken()。

单一职责：

第一个细节告诉我们，从业务模型上来说，不应该属于这个类的属性和方法，不应该被放到这个类里。比如 URL、AppID 这些信息，从业务模型上来说，不应该属于 AuthToken，所以我们不应该放到这个类中。

从业务模型来梳理属性和方法：

第二、第三个细节告诉我们，在设计类具有哪些属性和方法的时候，不能单纯地依赖当下的需求，还要分析这个类从业务模型上来讲，理应具有哪些属性和方法。
这样可以一方面保证类定义的完整性，另一方面不仅为当下的需求还为未来的需求做些准备。

 

Url 类

注意：

接口请求并不一定是以 URL 的形式来表达，还有可能是 Dubbo、RPC 等其他形式。为了让这个类更加通用，命名更加贴切，我们接下来把它命名为 ApiRequest。

 

CredentialStorage 类

 

3. 定义类与类之间的交互关系

类与类之间都有哪些交互关系呢？UML 统一建模语言中定义了六种类之间的关系。它们分别是：泛化、实现、关联、聚合、组合、依赖。关系比较多，而且有些还比较相近，比如聚合和组合。

泛化（Generalization）可以简单理解为继承关系。

public class A {
   
    ... }
public class B extends A {
   
    ... }

 </