CategoryResourceRepost/极客时间专栏/设计模式之美/设计原则与思想:面向对象/14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?.md
louzefeng d3828a7aee mod
2024-07-11 05:50:32 +00:00

18 KiB
Raw Blame History

在上一节课中针对接口鉴权功能的开发我们讲了如何进行面向对象分析OOA也就是需求分析。实际上需求定义清楚之后这个问题就已经解决了一大半这也是为什么我花了那么多篇幅来讲解需求分析。今天我们再来看一下针对面向对象分析产出的需求如何来进行面向对象设计OOD和面向对象编程OOP

如何进行面向对象设计?

我们知道,面向对象分析的产出是详细的需求描述,那面向对象设计的产出就是类。在面向对象设计环节,我们将需求描述转化为具体的类的设计。我们把这一设计环节拆解细化一下,主要包含以下几个部分:

  • 划分职责进而识别出有哪些类;
  • 定义类及其属性和方法;
  • 定义类与类之间的交互关系;
  • 将类组装起来并提供执行入口。

实话讲,不管是面向对象分析还是面向对象设计,理论的东西都不多,所以我们还是结合鉴权这个例子,在实战中体会如何做面向对象设计。

1.划分职责进而识别出有哪些类

在面向对象有关书籍中经常讲到,类是现实世界中事物的一个建模。但是,并不是每个需求都能映射到现实世界,也并不是每个类都与现实世界中的事物一一对应。对于一些抽象的概念,我们是无法通过映射现实世界中的事物的方式来定义类的。

所以,大多数讲面向对象的书籍中,还会讲到另外一种识别类的方法,那就是把需求描述中的名词罗列出来,作为可能的候选类,然后再进行筛选。对于没有经验的初学者来说,这个方法比较简单、明确,可以直接照着做。

不过,我个人更喜欢另外一种方法,那就是根据需求描述,把其中涉及的功能点,一个一个罗列出来,然后再去看哪些功能点职责相近,操作同样的属性,是否应该归为同一个类。我们来看一下,针对鉴权这个例子,具体该如何来做。

在上一节课中,我们已经给出了详细的需求描述,为了方便你查看,我把它重新贴在了下面。

  • 调用方进行接口请求的时候将URL、AppID、密码、时间戳拼接在一起通过加密算法生成token并且将token、AppID、时间戳拼接在URL中一并发送到微服务端。
  • 微服务端在接收到调用方的接口请求之后从请求中拆解出token、AppID、时间戳。
  • 微服务端首先检查传递过来的时间戳跟当前时间是否在token失效时间窗口内。如果已经超过失效时间那就算接口调用鉴权失败拒绝接口调用请求。
  • 如果token验证没有过期失效微服务端再从自己的存储中取出AppID对应的密码通过同样的token生成算法生成另外一个token与调用方传递过来的token进行匹配。如果一致则鉴权成功允许接口调用否则就拒绝接口调用。

首先,我们要做的是逐句阅读上面的需求描述,拆解成小的功能点,一条一条罗列下来。注意,拆解出来的每个功能点要尽可能的小。每个功能点只负责做一件很小的事情(专业叫法是“单一职责”,后面章节中我们会讲到)。下面是我逐句拆解上述需求描述之后,得到的功能点列表:

  1. 把URL、AppID、密码、时间戳拼接为一个字符串
  2. 对字符串通过加密算法加密生成token
  3. 将token、AppID、时间戳拼接到URL中形成新的URL
  4. 解析URL得到token、AppID、时间戳等信息
  5. 从存储中取出AppID和对应的密码
  6. 根据时间戳判断token是否过期失效
  7. 验证两个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、密码、时间戳这几个名词我们把它作为了方法的参数。
  • 第二个细节我们还需要挖掘一些没有出现在功能点描述中属性比如createTimeexpireTimeInterval它们用在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可以简单理解为继承关系。具体到Java代码就是下面这样

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

实现Realization一般是指接口和实现类之间的关系。具体到Java代码就是下面这样

public interface A {...}
public class B implements A { ... }

聚合Aggregation是一种包含关系A类对象包含B类对象B类对象的生命周期可以不依赖A类对象的生命周期也就是说可以单独销毁A类对象而不影响B对象比如课程与学生之间的关系。具体到Java代码就是下面这样

public class A {
  private B b;
  public A(B b) {
    this.b = b;
  }
}

组合Composition也是一种包含关系。A类对象包含B类对象B类对象的生命周期依赖A类对象的生命周期B类对象不可单独存在比如鸟与翅膀之间的关系。具体到Java代码就是下面这样

public class A {
  private B b;
  public A() {
    this.b = new B();
  }
}

关联Association是一种非常弱的关系包含聚合、组合两种关系。具体到代码层面如果B类对象是A类的成员变量那B类和A类就是关联关系。具体到Java代码就是下面这样

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类对象有任何使用关系我们都称它们有依赖关系。具体到Java代码就是下面这样

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) { ... }
}

看完了UML六种类关系的详细介绍不知道你有何感受我个人觉得这样拆分有点太细增加了学习成本对于指导编程开发没有太大意义。所以我从更加贴近编程的角度对类与类之间的关系做了调整只保留了四个关系泛化、实现、组合、依赖这样你掌握起来会更加容易。

其中泛化、实现、依赖的定义不变组合关系替代UML中组合、聚合、关联三个概念也就相当于重新命名关联关系为组合关系并且不再区分UML中的组合和聚合两个概念。之所以这样重新命名是为了跟我们前面讲的“多用组合少用继承”设计原则中的“组合”统一含义。只要B类对象是A类对象的成员变量那我们就称A类跟B类是组合关系。

理论的东西讲完了让我们来看一下刚刚我们定义的类之间都有哪些关系呢因为目前只有三个核心的类所以只用到了实现关系也即CredentialStorage和MysqlCredentialStorage之间的关系。接下来讲到组装类的时候我们还会用到依赖关系、组合关系但是泛化关系暂时没有用到。

4.将类组装起来并提供执行入口

类定义好了类之间必要的交互关系也设计好了接下来我们要将所有的类组装在一起提供一个执行入口。这个入口可能是一个main()函数也可能是一组给外部用的API接口。通过这个入口我们能触发整个代码跑起来。

接口鉴权并不是一个独立运行的系统而是一个集成在系统上运行的组件所以我们封装所有的实现细节设计了一个最顶层的ApiAuthenticator接口类暴露一组给外部调用者使用的API接口作为触发执行鉴权逻辑的入口。具体的类的设计如下所示

如何进行面向对象编程?

面向对象设计完成之后我们已经定义清晰了类、属性、方法、类之间的交互并且将所有的类组装起来提供了统一的执行入口。接下来面向对象编程的工作就是将这些设计思路翻译成代码实现。有了前面的类图这部分工作相对来说就比较简单了。所以这里我只给出比较复杂的ApiAuthenticator的实现。

对于AuthToken、ApiRequest、CredentialStorage这三个类在这里我就不给出具体的代码实现了。给你留一个课后作业你可以试着把整个鉴权框架自己去实现一遍。

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图也不可能把每个细节、交互都想得很清楚。在落实到代码的时候我们还是要反复迭代、重构、打破重写。

毕竟,整个软件开发本来就是一个迭代、修修补补、遇到问题解决问题的过程,是一个不断重构的过程。我们没法严格地按照顺序执行各个步骤。这就类似你去学驾照,驾校教的都是比较正规的流程,先做什么,后做什么,你只要照着做就能顺利倒车入库,但实际上,等你开熟练了,倒车入库很多时候靠的都是经验和感觉。

重点回顾

今天的内容到此就讲完了。我们来一块总结回顾一下,你需要掌握的重点内容。

面向对象分析的产出是详细的需求描述。面向对象设计的产出是类。在面向对象设计这一环节中,我们将需求描述转化为具体的类的设计。这个环节的工作可以拆分为下面四个部分。

1.划分职责进而识别出有哪些类

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

2.定义类及其属性和方法

我们识别出需求描述中的动词,作为候选的方法,再进一步过滤筛选出真正的方法,把功能点中涉及的名词,作为候选属性,然后同样再进行过滤筛选。

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

UML统一建模语言中定义了六种类之间的关系。它们分别是泛化、实现、关联、聚合、组合、依赖。我们从更加贴近编程的角度对类与类之间的关系做了调整保留四个关系泛化、实现、组合、依赖。

4.将类组装起来并提供执行入口

我们要将所有的类组装在一起提供一个执行入口。这个入口可能是一个main()函数也可能是一组给外部用的API接口。通过这个入口我们能触发整个代码跑起来。

课堂讨论

软件设计的自由度很大,这也是软件的复杂之处。不同的人对类的划分、定义、类之间交互的设计,可能都不大一样。那除了我今天给出的设计思路,你还有没有其他设计思路呢?

欢迎在留言区写下你的答案,和同学一起交流和分享。如果有收获,也欢迎你把这篇文章分享给你的朋友。