《雅码轩: Java哲思》003 不共情原则

雅码轩专栏, 干货, 无废话!

不共情原则

所有模块之间应该是互不感知的, 编写接口时, 应该只关注入参和出参 , 不应该考虑到对方服务是干啥的! 更不应该考虑对方调我的接口后应该怎么做! 只关注自己的抽象Service, 不需要去共情, 别的业务模块那复杂的调用链路和前端传参
所以我称之为不共情原则 , 可以理解为CAP定理中的A的概念, 在不共情原则下, 你则需要保证服务的高幂等性, 和健壮性

× 糟糕代码

	// 区块链放币
    @Override
    public void depositCoins(DepositCoinsDTO dto) {
    	// 你的内心: 这里APP进入了钱包详情, 一定有walletId, 直接用哈哈哈.
    	deposit(dto.getWalletId().hashCode());
    }
    

运行结果: walletId空指针

java.lang.NullPointerExceptin: null

发现问题了吗? 编写此服务的程序员, 在写代码的时候, 思考了外界所发生的场景, 从而影响了自己的代码, 独断专行地认为walletId一定不为null, 这里空指针的原因有很多, 例如黑客接口攻击, 前端js逻辑错误, walletId不小心为空, 前端传参单词写错等…

为了满足CAP中的A, 每个微服务应该为自己负责

√ 优雅代码

	// 区块链放币
    @Override
    public void depositCoins(DepositCoinsDTO dto) {
    	Assert.notNull(dto.getWalletId(), "钱包id必传");
    	// 前面做了校验, 这里可放心使用...
    	deposit(dto.getWalletId().hashCode());
    }
    

这样就保证了服务可用性, 给出了友好提示, 达到了不共情原则

---

多提一嘴:

上述代码Assert是hutool工具中的断言工具类, 此工具类抛出的是IllegalParamsException(参数不合法异常), 为了与RuntimeException 区分开了, 和系统安全性考虑, 在全局异常处理器@ControllerAdvice中, 应区分多种处理器, 遇到RuntimeException 则不返回e.getMessage(), 未知的错误不能随便给用户看, 而是仅打印log.
遇到IllegalParamsException 则在响应体中返回e.getMessage(), 因为这些提示是需要给用户看的.