使用面向对象抽取业务算法

描述

前面我们已经对领域内的名词进行了抽取，并且已经确定了业务流程中参与的核心对象。
但是对象只是静态的描述，系统中往往会有很多的业务操作，偏算法的，之前我们说过
领域内的对象往往是比较稳定不怎么变化的，但是，业务的流程以及业务操作这些是往往
千变万化，防不胜防，那么我们如何去及时发现这些系统内变化点，并且如何使用面向对象
的方式去抽象，封装它呢？，下面就简单介绍我们大神的一些个人经验，也在此记录一下。

目的

关注系统中的变化点或者说业务的流程中某个节点的多变的算法，
提供系统的可维护性和扩展性。

步骤

先说步骤，步骤后面跟着一些场景进行解析，试着理解步骤。

找出变化点

这是第一步也是关键的一步，如果你连这个系统中的变化点都找不到，下面的工作也就
无从谈起，所以我们在这个阶段就要去细心观察找出那些业务的变化点，
一般的我们可以从产品的原型中，产品的沟通中可以找到：
关注那些从描述上看起来不一样，却又是在做同一件事的场景。

去限定词

找出这个场景或者算法每次而且每条都出现的领域名词和没有限定词的动词，其他的全部可以忽略。
简单的说就是把场景中的不断出现的领域名词都删除掉，留下动词。

抽取动词

根据上一步的操作，我们对场景中的动词需要进行抽象一下，使用一个动作统一概括。

抽取接口

将这个动作作为一个接口存在，确定这个接口中的方法用来做什么以及它的输入，输出。
说白了就是定义一个函数的名称，参数，返回值。
一般来说输入的要是抽象中每次都出现的名词，输出是这个抽象需要的内容。

聚合接口

并不是说一个接口只能有一个方法，实际上，有些方法是成双成对，甚至是成几对出现的。
如果发现两个接口合在一起刚好可以表达一个完整的事情就可以将这两个接口合并成一个接口。

实例解析

场景一描述

在优学习（教育网站http://www.uxuexi.com）这个网站上为用户提供了很多的服务，比如：
可以购买单个视频进行观看，
也可以将视频打包购买进行观看，
可以购买阅卷服务让老师给用户的试卷进行评阅
也可以购买约课的服务让老师上门或者在线进行辅导
这个业务场景是一个变化点，因为平台中可以添加任何具有服务性质的东西让用户购买。
这里可以抽取一个商品的概念，其实用户购买的就是商品，不管它是视频，评卷服务，辅导服务都是商品。
所有我们按照步骤就这么做。

去限定词：

购买xx商品得到xx商品的服务

抽取动词：

购买，服务

抽取接口：

IBuy
接口中的方法：
方法名称：goToBuy
参数：商品
执行：完成购买
返回：空
IService
方法名称：supply
参数：商品
执行：商品提供的服务
返回：空

类图如下：

合并接口

我们会发现但凡我们需要增加一个商品都需要实现这两个接口，这个时候就说明我们可以
将这两个接口抽取成一个接口，这就是聚合接口。

类图如下：

场景二描述

在电商网站中支付是一个重要的环节，往往会有以下需求：
用户可以使用支付宝完成订单支付
用户可以使用微信完成订单支付
用户可以使用银行卡的方式完成订单支付

找出变化点

这个场景的变化点就是用户可以使用多种方式完成支付。

去限定词

使用xx方式完成订单支付

抽取动词

这个场景强调的动作是支付，所以动词应该就是：去支付
但是，我们知道每一个支付都需要我们提供给一个支付完成的回调供支付平台通知支付结果，
所以这里要添加一个动作：完成支付

抽取接口

接口中的方法：
方法名称：goToPay
参数：订单
执行：完成购买
返回：空
方法名称：finish
参数：订单
执行：完成购买
返回：空

类图：

场景三描述

在做优学习网站时，出现了这么一个场景，每一个视频的播放需要鉴权，
也就是说用户点击某个视频的时候由后台决定他是否有观看的权限。
情况如下：
免费的视频可以观看
课程包中的第一个视频可以观看
购买的视频中包含这个视频的可以观看
请求来源的域名如果在白名单中可以观看所有视频
网站的合作商可以观看所有视频
等等。。。。

找出变化点

判断视频是否可以播放的条件在不断增加，这就是一个变化点。

去限定词

视频是否可以观看

抽取动作

判断视频是否可以观看其实就是鉴权，所以动作就是：是否可以播放

抽取接口

接口名称：IVideoAuthentication
接口中的方法：
方法名称：goToPay
参数：视频id
执行：判断是否具有播放权限
返回：布尔

类图：

设计心得

接口有了，但是我们怎么更好组织它呢？
一般的场景我们可以采用以下方案：

平行算法

如果这些接口的具体实现在同一时刻只能出现一个具体算法，这些算法又可以平行替换，
我们就可以参考“策略模式"去设计。

串行算法

如果这些接口的具体实现在同一时刻有可能需要组合一起去完成某个功能这就是串行，
我们可以使用”职责链模式“去设计。

考虑重用

如果这些算法之间有一些公用的逻辑，业务，算法我们可以考虑使用，模板模式，装饰模式去解决重复问题，
让我们的设计更加合理有扩展性。