香山网站建设,国外免费空间网站申请,门户网站建设发展趋势,聊城做网站的公司在上一节课中#xff0c;针对接口鉴权功能的开发#xff0c;我们讲了如何进行面向对象分析#xff08;OOA#xff09;#xff0c;也就是需求分析。实际上#xff0c;需求定义清楚之后#xff0c;这个问题就已经解决了一大半#xff0c;这也是为什么我花了那么多篇幅来讲…在上一节课中针对接口鉴权功能的开发我们讲了如何进行面向对象分析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、密码、时间戳这几个名词我们把它作为了方法的参数。第二个细节我们还需要挖掘一些没有出现在功能点描述中属性比如 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 接口。通过这个入口我们能触发整个代码跑起来。 接口鉴权并不是一个独立运行的系统而是一个集成在系统上运行的组件所以我们封装所有的实现细节设计了一个最顶层的 ApiAuthencator 接口类暴露一组给外部调用者使用的 API 接口作为触发执行鉴权逻辑的入口。具体的类的设计如下所示
如何进行面向对象编程
面向对象设计完成之后我们已经定义清晰了类、属性、方法、类之间的交互并且将所有的类组装起来提供了统一的执行入口。接下来面向对象编程的工作就是将这些设计思路翻译成代码实现。有了前面的类图这部分工作相对来说就比较简单了。所以这里我只给出比较复杂的 ApiAuthencator 的实现。
对于 AuthToken、ApiRequest、CredentialStorage 这三个类在这里我就不给出具体的代码实现了。给你留一个课后作业你可以试着把整个鉴权框架自己去实现一遍。
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;}Overridepublic void auth(String url) {ApiRequest apiRequest ApiRequest.buildFromUrl(url);auth(apiRequest);}Overridepublic 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 接口。通过这个入口我们能触发整个代码跑起来。
