第一部分:实战二
实战二(上)
案例介绍和难点剖析
- 以一个真实的开发案例,从基础的需求分析、职责划分、类的定义、交互、组装运行讲起,将最基础的面向对象分析、设计、编程的套路给你讲清楚,为后面学习设计原则、设计模式打好基础。
- 真实案例,给你的微服务增加接口调用鉴权功能。
需求不明确
- leader 给到的需求过于模糊、笼统,不够具体、细化,离落地到设计、编码还有一定的距离。
- 面向对象分析可以粗略地看成“需求分析”。
缺少锻炼
- 鉴权作为一个跟具体业务无关的功能,我们完全可以把它开发成一个独立的框架,集成到很多业务系统中。
- 开发这样通用的框架,对工程师的需求分析能力、设计能力、编码能力,甚至逻辑思维能力的要求,都是比较高的。
对案例进行需求分析
第一轮基础分析
设计通过AppID和密钥来认证。
第二轮分析优化
防止“重放攻击”,增加加密token验证。
第三轮分析优化
依然有“重放攻击”风险,引入时间戳作为随机变量。
第四轮分析优化
- 在允许时间范围内(比如1分钟),依然有攻击风险,这是一个攻防策略。
- 多端多AppID要如何存储,设计时要留有扩展点,当更换存储时减少代码改动,多运用面向对象的编程思想。
- 需求分析主要做的是一个分析的过程,一个思考的过程,如何循序渐进,拆解需求,完善设计,迭代优化。不用过分盯着这个具体案例还不够完善安全等。
最终确定需求
- 调用方进行接口请求的时候,将 URL、AppID、密码、时间戳拼接在一起,通过加密算法生成 token,并且将 token、AppID、时间戳拼接在 URL 中,一并发送到微服务端。
- 微服务端在接收到调用方的接口请求之后,从请求中拆解出 token、AppID、时间戳。
- 微服务端首先检查传递过来的时间戳跟当前时间,是否在token 失效时间窗口内。如果已经超过失效时间,那就算接口调用鉴权失败,拒绝接口调用请求。
- 如果 token 验证没有过期失效,微服务端再从自己的存储中,取出 AppID 对应的密码,通过同样的 token 生成算法,生成另外一个 token,与调用方传递过来的 token 进行匹配;如果一致,则鉴权成功,允许接口调用,否则就拒绝接口调用。
实战二(下)
如何进行面向对象设计?
划分职责进而识别出有哪些类
- 回顾上文中需求分析的四点详细需求描述,将需求拆解成小的功能点,遵循“单一职责”。
- 7个功能点列述:
- 把 URL、AppID、密码、时间戳拼接为一个字符串;
- 对字符串通过加密算法加密生成 token;
- 将 token、AppID、时间戳拼接到 URL 中,形成新的URL;
- 解析 URL,得到 token、AppID、时间戳等信息;
- 从存储中取出 AppID 和对应的密码;
- 根据时间戳判断 token 是否过期失效;
- 验证两个 token 是否匹配;
- 根据功能点划分三个核心类:
- AuthToken:1、2、6、7 都是跟 token 有关,负责 token的生成、验证
- Url:3、4 都是在处理 URL,负责 URL 的拼接、解析
- CredentialStorage:5 是操作 AppID 和密码,负责从存储中读取 AppID和密码
- 复杂的需求开发,要先进行模块划分,然后在模块内部分别拆解功能点。
定义类及其属性和方法
AuthToken:
- 一般情况,识别需求中的名词为属性,动词为方法
- 属性:token,createTime,expireTimeInterval
- 方法:getToken(),isExpired(),match()
- 并不是所有出现的名词都定义为属性,有的名词作为了方法得参数,因为这些名词从业务角度不属于当前类
- 还要挖掘出没在功能点中得属性(在方法中使用)和方法(保证类的完整性)
Url类:
- 类名:ApiRequest
- 属性:baseUrl,token,appId,timestamp
- 方法:getBaseUrl(),getToken(),getAppId(),getTimestamp()
CredentialStorage类:
- 设计成接口的形式,基于接口而非实现的编程
- 可以灵活应对更换存储方式
定义类与类之间的交互关系
- UML统一建模语言中定义的六种类之间的关系:
- 泛化:继承
- 实现:接口和实现类
- 聚合:A类对象包含B类对象,销毁A类对象不影响B类对象
- 组合:A类对象包含B类对象,B类对象不可单独存在
- 关联:包含聚合和组合
- 依赖:包含关联,只要A类对象和B类对象有任何使用关系
- 简化的定义:
- 泛化
- 实现
- 依赖
- 组合:组合、聚合、关联,并且可以和“多用组合少用继承”中的“组合”统一含义
泛化(Generalization):
public class A { ... }
public class B extends A { ... }
实现(Realization):
public interface A {...}
public class B implements A { ... }
聚合(Aggregation):
public class A {
private B b;
public A(B b) {
this.b = b;
}
}
组合(Composition):
public class A {
private B b;
public A() {
this.b = new B();
}
}
关联(Association):
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):
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) { ... }
}
将类组装起来并提供执行入口
- 设计一个最顶层的 ApiAuthenticator 接口类,暴露一组给外部调用者使用的 API 接口,作为触发执行鉴权逻辑的入口。
如何进行面向对象编程?
- 面向对象编程的工作,就是将这些设计思路翻译成代码实现。
- ApiAuthenticator 接口的实现类代码,此实现类中AppID和密码是使用mysql存储的。
public interface ApiAuthencator {
void auth(String url);
void auth(ApiRequest apiRequest);
}
public class DefaultApiAuthencatorImpl implements ApiAuthencator {
private CredentialStorage credentialStorage;
public ApiAuthencator() {
this.credentialStorage = new MysqlCredentialStorage();
}
public ApiAuthencator(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, passw
if (!serverAuthToken.match(clientAuthToken)) {
throw new RuntimeException("Token verfication failed.");
}
}
}
辩证思考与灵活应用
- 文中作者将面向对象分析、设计、实现,每个环节的界限划分都比较清楚、细致,即使是没有太多经验的初级工程师,也可以按部就班地做。
- 然而大部分情况,这些过程可能是在大家脑子里完成的,不要花太多时间放在设计出完美的类图、UML图上,不要拘泥于形式,死搬理论概念。即使设计的时候有遗漏,我们边开发、边思考、边重构,反复迭代,也是代码演变的正常流程。