【设计模式之美】面向对象分析方法论与实现（一）：需求分析方法论 描述了如何进行需求描述，本文描述
根据示例需求，如何来进行面向对象设计（OOD）和面向对象编程（OOP）。
- 描述怎么根据需求描述确定类
- 定义类与类之间的关系
3. 拼装类实现鉴权逻辑
面向对象分析的产出是详细的需求描述，那面向对象设计的产出就是类。
在面向对象设计环节，我们将需求描述转化为具体的类的设计。我们把这一设计环节拆解细化一下，主要包含以下几个部分：
根据需求描述，把其中涉及的功能点，一个一个罗列出来，然后再去看哪些功能点 职责相近，操作同样的属性，是否应该归为同一个类。
需求描述重放
拆解需求
拆解出来的每个功能点要尽可能的小。每个功能点只负责做一件很小的事情，要符合“单一职责”。拆解需求后，得到的功能点列表：
- 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 这个操作。
当然，这是一个初步的类的划分，其他一些不重要的、边边角角的类，我们可能暂时没法一下子想全，但这也没关系，面向对象分析、设计、编程本来就是一个循环迭代、不断优化的过程。
通过分析需求描述，识别出了三个核心的类，它们分别是 AuthToken、Url 和 CredentialStorage。
现在我们来看下，每个类都有哪些属性和方法。我们还是从功能点列表中挖掘。
AuthToken
我们可以发现这样三个小细节。
- 并不是所有出现的名词都被定义为类的属性 ，比如 URL、AppID、密码、时间戳这几个名词，我们把它作为了方法的参数。
- 需要挖掘一些没有出现在功能点描述中属性 ，比如 createTime，expireTimeInterval，它们用在 isExpired() 函数中，用来判定 token 是否过期。
- 我们还给 AuthToken 类添加了一个功能点描述中没有提到的方法 getToken()。
单一职责：
第一个细节告诉我们，从业务模型上来说，不应该属于这个类的属性和方法，不应该被放到这个类里。 比如 URL、AppID 这些信息，从业务模型上来说，不应该属于 AuthToken，所以我们不应该放到这个类中。
从业务模型来梳理属性和方法：
第二、第三个细节告诉我们，在设计类具有哪些属性和方法的时候，不能单纯地依赖当下的需求，还要分析这个类从业务模型上来讲， 理应具有哪些属性和方法 。
这样可以一方面保证类定义的完整性，另一方面不仅为当下的需求还为未来的需求做些准备。
Url 类
注意：
接口请求并不一定是以 URL 的形式来表达，还有可能是 Dubbo、RPC 等其他形式。为了让这个类更加通用，命名更加贴切，我们接下来把它命名为 ApiRequest。
CredentialStorage 类
类与类之间都有哪些交互关系呢？UML 统一建模语言中定义了六种类之间的关系。它们分别是：泛化、实现、关联、聚合、组合、依赖。关系比较多，而且有些还比较相近，比如聚合和组合。
泛化 （Generalization）可以简单理解为继承关系。
public class A { ... }
public class B extends A { ... }
实现 （Realization）一般是指接口和实现类之间的关系。
public interface A {...}
public class B implements A { ... }
聚合
（Aggregation）是一种包含关系，局部变量的感觉。
A 类对象包含 B 类对象，B 类对象的生命周期不依赖 A 类对象的生命周期，比如课程与学生之间的关系。
public class A {
private B b;
public A(B b) {
this.b = b;
}
}
组合 （Composition）也是一种包含关系，成员变量的感觉。
A 类对象包含 B 类对象，B 类对象的生命周期依赖 A 类对象的生命周期，B 类对象不可单独存在，比如鸟与翅膀之间的关系。
public class A {
private B b;
public A() {
this.b = new B();
}
}
关联 （Association）是一种非常弱的关系， 包含聚合、组合两种关系 。
具体到代码层面，如果 B 类对象是 A 类的成员变量，那 B 类和 A 类就是关联关系。
public class A {
private B b;
public A(B b) {
this.b = b;
}
}
或者
public class A {
private B b;
public A() {
this.b = new B();
}
}
依赖 （Dependency）是一种 比关联关系更加弱的关系 ，包含关联关系。
不管是 B 类对象是 A 类对象的成员变量，还是 A 类的方法使用 B 类对象作为参数或者返回值、局部变量，只要 B 类对象和 A 类对象有任何使用关系，我们都称它们有依赖关系。
public class A {
private B b;
public A(B b) {
this.b = b;
}
}
或者
public class A {
private B b;
public A() {
this.b = new B();
}
}
或者
public class A {
public void func(B b) { ... }
}
我们这里只关注：泛化、实现、组合、依赖。
接下来我们要将所有的类组装在一起，提供一个执行入口。这个入口可能是一个 main() 函数，也可能是一组给外部用的 API 接口。通过这个入口，我们能触发整个代码跑起来。
接口鉴权并不是一个独立运行的系统，而是一个 集成在系统上运行的组件 ，所以， 我们（通过接口）封装所有的实现细节 ，设计了一个最顶层的 ApiAuthenticator 接口类，暴露一组给外部调用者使用的 API 接口，作为触发执行鉴权逻辑的入口。
面向对象设计完成之后，我们已经定义清晰了类、属性、方法、类之间的交互，并且将所有的类组装起来，提供了统一的执行入口。
接下来，面向对象编程的工作， 就是将这些设计思路翻译成代码实现 。
有了前面的类图，这部分工作相对来说就比较简单了。所以，这里只给出比较复杂的 ApiAuthenticator 的实现。
public interface ApiAuthenticator {
void auth(String url);
void auth(ApiRequest apiRequest);
}
public class DefaultApiAuthenticatorImpl implements ApiAuthenticator {
private CredentialStorage credentialStorage;
public DefaultApiAuthenticatorImpl() {
this.credentialStorage = new MysqlCredentialStorage();
}
public DefaultApiAuthenticatorImpl(CredentialStorage credentialStorage) {
this.credentialStorage = credentialStorage;
}
@Override
public void auth(String url) {
ApiRequest apiRequest = ApiRequest.buildFromUrl(url);
auth(apiRequest);
}
@Override
public void auth(ApiRequest apiRequest) {
String appId = apiRequest.getAppId();
String token = apiRequest.getToken();
long timestamp = apiRequest.getTimestamp();
String originalUrl = apiRequest.getOriginalUrl();
AuthToken clientAuthToken = new AuthToken(token, timestamp);
if (clientAuthToken.isExpired()) {
throw new RuntimeException("Token is expired.");
}
String password = credentialStorage.getPasswordByAppId(appId);
AuthToken serverAuthToken = AuthToken.generate(originalUrl, appId, password, timestamp);
if (!serverAuthToken.match(clientAuthToken)) {
throw new RuntimeException("Token verfication failed.");
}
}
}
在平时的工作中，大部分程序员往往都是在脑子里或者草纸上完成面向对象分析和设计，然后就开始写代码了，边写边思考边重构，并不会严格地按照刚刚的流程来执行。
而且， 说实话，即便我们在写代码之前，花很多时间做分析和设计，绘制出完美的类图、UML 图，也不可能把每个细节、交互都想得很清楚 。
在落实到代码的时候，我们还是要反复迭代、重构、打破重写。
参考：《设计模式之美》