背景
组内的数据管理平台承担着公司在线特征数据的管理工作。开发通过提交工单接入我们的数据系统。工单模型在设计之初只考虑到了一种类型的工单(新特征的申请),对于工单生命周期的每个节点分别用一个接口去实现。随着业务迭代,还有一些操作也需要通过走工单让管理员审批执行。此时最初的工单模型不能满足需求,此时为了让系统先用起来,我们的做法是写单独的接口去实现...这样虽然能用,但是导致后端代码里多出来了很多API。趁着过年前几天业务不多,我对工单部分代码进行了重构,希望达到的效果是后续不同类型的工单复用同一套工单流程,同时减轻前后端交互的成本。
需求分析
经过抽象,对于我们的系统不同类型的工单,工单的生命周期都是一样的,工单只有这些状态:
工单这几个状态要执行的操作差别是很大的,所以分别用不同接口去实现每一种工单状态,这其中代码的复用不多。工单状态和执行操作如下图:
前面说到,在系统之前的代码里面不同类型的工单分别用不同的API实现,看代码可以发现,不同类型的工单在生命周期的一个节点里面做的操作是类似的。比如对于新建工单,重构代码之前操作是这样:
增加工单种类之后,新建工单操作是这样:
其中校验前端参数、调用工单实例、发送通知的代码都是可以复用的。只有工单操作这一块行为有所区别,工单操作简单抽象一下分为两种:
实现思路
考虑到前端同学的开发成本,这次重构复用之前的接口,在每个接口参数里面增加一项工单类型(worksheetType),根据工单类型,做不同的操作。
重构的思路有两种,一种是"函数式编程"(FP),另一种是"面向对象编程"(OOP)。这里晒出一张经典的图片,hhh...
实现对比
为了对比两种方式,分别实现了demo。OOP如下:
FP如下:
以上就是本篇文章【[Golang]一个工单系统的重构过程-FP vs OOP】的全部内容了,欢迎阅览 ! 文章地址:http://yybeili.xhstdz.com/news/1656.html
栏目首页
相关文章
动态
同类文章
热门文章
网站地图
返回首页 物流园资讯移动站 http://yybeili.xhstdz.com/mobile/ , 查看更多