输出内容价值 | 极客写作训练营

day3 输出内容价值 1206

• 每日写作打卡：写一篇文章，记录自己最近一次解决工作中难点的经历，不少于 500 字（必选）。

• 加练挑战：选择一讲对你有帮助极客时间专栏课程，写一写这节课好在哪里，字数不限（可选）。

每日写作打卡

思考半天，最近工作中似乎没有难点的经历（技术问题），那就简单描述一下最近写代码（Java 语言）的一个思考，看完郑大《代码之丑的》实践，内容涉及知识点：单一职责原则、封装行为、减少暴露细节，实践内容是原代码、优化后的代码、为什么这么优化。

实现的功能就是，调用 AWS 服务 S3 进行文件上传，上传 S3 需要参数：endpoint、accessKey、secretKey、bucketName、objectName

原代码（忽略爆红的地方）

UML

第一次尝试这么正式的 UMl，虽然不太可观，先就这样吧

同事写的代码

原代码的问题，我现在有另外一个业务方要上传文件到另外一个桶，原代码是账单桶、我现在要上传到签名桶

绝大部分人可能会如此改造

优化 AwsS3Rpc 的方法为，参数由上游控制public void uploadFile(String bucketName, String objectName, String filePath) throws Exception {

FileService 业务代码依赖 AwsS3Config 获取 AwsS3Config

上面的代码有一个问题

如果当获取 bucketName 的逻辑变了，那就需要在散落的各个地方做修改，这里就违反了单一职责原则，同时也是《重构》那本书的 Bad smell 的“散弹式修改”，回到封装的定义上，封装是封装行为，那获取 Sign 桶的 name，那应该封装一个具体的行为，封装到哪里呢？封装到 AwsS3Rpc 里，优化代码后

业务方代码由 awsS3Config.getXXName()修改为awsS3Rpc.getSignBucketName()

总结

一句话，请记住，如果一个变动引起多个地方改动，那可能缺少封装

加练挑战

没时间了，先不写了