「这是我参与2022首次更文挑战的第6天，活动详情查看：2022首次更文挑战」。
类似这样的代码：
@Component
public class ThirdPartyContentData {
@Autowired
private ThirdPartyContentMapper thirdPartyContentMapper;
public List getList(long timestamp) {
return thirdPartyContentMapper.getList(timestamp);
}}
明明可以直接使用 thirdPartyContentMapper.getList(timestamp) 为什么还要嵌套一个类或方法呢？这是一个Mapper的调用，还有很多类似的调用，像Lion配置的客户端调用、Squirrel客户端、外部依赖RPC的调用，都会有类似的封装。
学员问的这个问题很好，一个好的问题不仅仅意味着学员在思考，还意味着他在进步，开始意识到工程实现的差异，会有深层次的考虑。当然作为导师，更重要的也是引导其思考，帮助他构建框架。类似的指导还有这篇。如果对问题的回答，抽象和总结不足，不仅学员学习效率低，导师也会陷入无尽的细节和繁琐之中。
工程设计领域，耳熟能详的也比较有限，正好碰到这个问题，用来做“今日份十分钟” 。 这一类设计原则是：任何外部依赖均要进行项目内的封装。 反过来说也就是禁止项目直接使用未进行封装的外部依赖。
这样设计好处巨大，而弊端几乎忽略不计，仅仅增加一点点编码量。
好处可以简练罗列一些：
- 外部依赖升级，就只用升级一处实现即可，也容易做兼容；
- 外部数据结构变更，就只用作一处变更和兼容，上层以来甚至都不会感知数据结构变动；
- 统一的监控、降级、缓存策略控制收口；
- 统一的外部服务篡改控制、设插件钩子位置等；
这个工程实现原则，同学们操作起来，没有例外的方案还是很容易实践和提升的。
未来的#今日份十分钟# 再找机会分享其他工程实践原则或理念。
