aes加密 java_拒绝教条，反思 Java 面向接口编程

面向接口编程

有一段时间，我是面向接口编程的坚决执行者；而且在大多数场合，我也完全认可并实践面向接口编程。

但凡事总有例外，我也在反思面向接口编程

套娃式开发

java 比较经典的一种套娃场景就是数据库里一些 CURD 的 service 对 mapper(或 dao) 的封装，很多时候，service 和 mapper 的接口定义是一样的，service 的实现无非就是简单的调用一次 mapper 的实现，在长期的开发实践里，我甚至做了一个代码生成器，自动帮我完成 service 到 mapper 的套娃

我甚至还在一些项目里见过 3 层套娃：service 里注入 dao，dao 里注入 mapper，mapper 的最终实现由 mybatis 框架注入。为了看到某些业务逻辑的 sql 语句，要跳转多次，我不由得发出灵魂质问：有必要吗？

java 还不够繁琐吗？用 python 写几十行代码可以搞定的需求，java 可能连配置文件都没有写完——就不能简洁一些吗？

助手类

所谓助手类是一些以 Helper 结尾的类，大多数时候它和 utils 工具类很相似；不同的是它没法提供静态方法，因为它需要一个实例化的过程，这个实例化过程一般是因为它需要外部注入一些依赖

比如一个加密的助手类，采用的算法是 AES，但是密钥是从配置中心注入的，并且还支持配置中心修改后热加载，这样就不能用一个静态的工具类了，那么我们就可以把它实现为一个助手类，如下示例

public class EncryptHelper {        @Value("aes_key")    private String aesKey;            public String encrypt(String plainText) {        return AesUtil.encryptHex(plainText, aesKey);    }}

又比如，我们的广告竞价业务采用的二价，计算一批候选广告的价格是可以用一个静态工具类来完成的，但随着业务的发展，我们的二价支持压榨因子，而这个压榨因子是可以由运营同学随时修改的，这样计算价格的静态工具类就不得不重构成支持注入压榨因子的助手类

这种助手类本质上就是个工具类，如果一定要抽取出接口来就会非常别扭

我的实践

拒绝套娃

• 如果 service 就是 mapper 的简单套娃，那么就不需要 service 了，直接用 mapper
• 一些简单业务，需要多个 mapper 一起完成，如果重用性不高，也不会专门声明一个 service 来实现

助手类

需要谨慎区分当前场景是适用 service 还是 helper，如果确定是 helper，不需要抽象出接口