背景

入职不久后，负责公司的一个财务模块，主要就是每个月财务需要月结，然后需要对账。对于小公司来说财务人员一般通过excel进行数据收集和透视分析就能完成大部分任务。但是我这家公司算是一个中等规模公司，引入了很多系统，销售管理端有ERP，OMS，WMS等，财务端主要是金蝶（kingdee）系统，更确切的说目前用的是SaaS版的金蝶云。所以为了协助财务能够更快的对账，IT部门需要收集和整合各业务系统数据到一个数据库中，然后进行报表或BI展示

金蝶云SaaS系统

ERP系统

正好前同事之前做了一个小系统里边有这样的功能，于是我便去看看能不能直接拿来复用，然后便去翻阅了下源代码，都是hardcode（硬编码）。虽然能满足当前功能，但是一旦新增功能那么就需要复制大量重复代码去拼凑，而且修改一个功能要同时修改多个地方。下面只展示了其中一个业务方法。

hardcdoe 01

hardcode 02

此刻心里想着是否可以自己写个通用的对接金蝶的SDK，把对金蝶操作的所有细节屏蔽掉，只提供对应的登录认证（只让客户端提供相应的账号密码即可），查询，保存，更新，删除等接口。不过根据多年的开发经验，我觉得金蝶肯定会提供这样的SDK，于是便去官方去查找了，找了半天硬是没找到（据说现在已经有了）。毕竟后面系统和代码是我自己维护呀，我不能让自己这样麻木下去，所以还是干点有趣的事情，让工作不要太乏味，于是在兼顾平日的工作基础上去花了点时间去手动写个金蝶SDK，目前已经挂到了gitee上，感觉效果还不错。有兴趣的同学可以去看看。下图是代码库的统计情况。

kingdee-k3cloud-webapi

下面我可以跟大家简单分析下代码的结构。

kingdee-k3coud-webapi解析

首先，要解决几个痛点

1. 客户端不应该再关心登录认证问题，只需要提供账号密码即可
2. 开箱即用的接口并保证接口参数范围最小化
3. 面向对象编程而不是让大量源自于一个对象的属性或方法暴露到代码的各个地方
4. SDK的扩展性要高

首先在解决上面几个痛点之前，我们要用抽象的角度来思考金蝶系统相对于我们目前的平台属于什么样的一个角色。其实可以把它类比一个数据库，我需要通过用户名和密码，然后去操作它（查询，新增，删除，更新）。于是在写具体实现之前，我先做个顶层ApiService。

ApiService

其实看完这个接口每个方法就很清楚接下来要做的事情，我来简单分析下：

getEndPoint：客户端提供的服务地址

getService：何种服务，新增 or 查询

getAuth：认证功能

execute：执行请求和处理数据

有了对金蝶抽象的认识便自然有了上面的抽象ApiService，光有抽象还不行，我们要实现这个接口才行。但是仔细再想想，是不是每个实现的接口都有通用的行为，比如：登录认证不需要每个服务都要写一遍，通用日志打印也不需要每个实现类去打一遍。很自然我们便有了通用抽象类的想法（可以理解为模板方法，也是个重要的设计模式）。往下看↓↓↓

CommonService01

CommonService02

这样的话，我们便解决了痛点1的登录问题，相当于把登录内置化，客户端不用关心。同时也解决了痛点4的SDK的扩展问题，后面如果金蝶那边新增服务功能，我只要继承通用CommonService这个类就行了。

各实现类

接下来就是如何让客户端更方便的去操作了，此刻我想到了Spring中的各大Template操作，比如：JdbcTemplate，RedisTemplate等等，想想他们的思想，感觉很直观很方便啊。于是我便整了一个K3CloudTemplate，大家可以看下部分实现：

K3CloudTemplate

这样便解决了痛点2的开箱即用并保证参数范围最小化（比如这边的BillQuery，BillSave，我们可以把金蝶的表单看作一个个对象并且抽出共性而不是传递大量参数）。那么下面就来看下表单是如何抽象封装的。

首先，我大概看了下金蝶的请求文档，发现不同的接口请求都需要传递通用的参数，比如：formId，于是表单也应该有个顶层父类以方便有共用的属性或行为。然后便有了BillEntity这个顶层实体。

BillEntity

接着就是根据不同的表单类型去进行扩展即可，如下：

BillQuery

BillSave

可以看出，BillQuery明显和BillSave不一样，BillQuery更复杂一点，因为查询应对的业务场景更多，比如：需要查询哪些字段，条件是什么，返回多少行。这些都被封装到BillQuery这个对象里边。如果你用面向过程和堆代码的思维去写这个查询，就出现文章开头那种情况，涉及到查询的地方可能都要根据金蝶的api去拼接查询字段，条件等，而不是把它当作一个查询对象并屏蔽一些通用行为。这便解释了痛点3的对象属性分散化的问题。

总结

经过以上的折腾，我总结了几点经验：

• 技术最终为业务服务，下手前先衡量各方业务边界，这样才能去抽象和取舍
• 能用面向对象编程就决不用面向过程，且不过度封装
• 汲取开源经典框架思想和最佳实践
• 不重复造轮子
• 独立的思考能力，不麻木，不讲究

感谢大家的阅读，码字不易，帮忙分享下或给个赞和关注呗[呲牙]