记一次公共服务分离

概览

原来写了一个mybatis可视化自动生成工具。为了主体代码不可见，并且适用于多个不同项目。对这个项目做了公用部分分离。

原则采用了，公共服务下沉，业务服务上浮的原则。主要难点在于：之前多为过程写法，如何抽离公共服务，易于支持扩展特异服务。小难点：区分是公共服务还是特异服务，分离并且可更改。

要求达到的目标是，特异需求都不再需要改公共服务。假如我要实现一个业务，就改底层原则。这样底层就会复杂成一个怪物。并且这个模块就要维护和本不该自己维护的东西，于后期再改代码非常不利。

需要配置

总体来说约定大于配置的方式很适合这种项目。所以很多都有默认参数。

数据库相关：

数据库连接地址，账号、密码。jar位置，加载器是哪一个，自定义的数据库字段读取类型。

每个库相关

每个库的名字，每个库可能会有的额外后缀。包名

特异服务和通用服务

什么是特异服务，当我有一个需求的时候，这个需求只会影响到这一个项目。这就是特异性的东西。这是绝对不能放在抽离出来的公用服务里。这样会有一个问题。比如项目1和项目2都引用了一个东西项目1把底层改了，项目2出错了。这就让项目2很委屈了。

抽离方式

比如对我之前对一个库生成出来的类会有特殊处理。这个东西能用boolean来划分吗？没做分离之前是可以的，但是这样做的方式好吗，当时我觉得很不错。但是分离之后，这样并不好，假如我有另一个库生成的类也要做处理，他俩处理方式还不一样。这必然会造成冲突。我本来是继承重写对生成累的重写方式。这样会有很多重复代码。并且对两个库都要根据名字处理，这样就会非常的糟糕、能实现吗，能！实现的好吗，只能说有点“some body”的味道。这里最实用的还是注册使用的方式。完全解耦，并且扩展很容易。这里大量重构才解决了这个问题。只能说之前耦合太高了，抽离多个改写文件的方法。分散到了不同的子类去实现。易于理解、维护、扩展的多。正好符合了少修改最好不修改，易于继承和扩展的原则。