6 篇博文 含有标签「接口设计」

2021 年很多 Node.js 项目开始接入 TypeScript，代码补全和重构体验都会好很多。但这时也特别容易出现一个错觉：既然参数已经有类型了，接口是不是就安全了？

BFF 最容易让团队上手的价值，是它能把前端要的多个接口结果拼成一个更顺手的响应。但编排一旦做顺了，也特别容易越界。

Go 学久一点以后，很多人都会记住一句话：interface 要小。但真到项目里，接口问题往往不是“大或小”这么简单，而是抽象出现得太早。实现只有一种、调用方式还没定稳，就先定义一堆 UserService、OrderRepository 接口，最后只会让代码多一层跳转。

“接口和抽象类怎么选”几乎是每个 Java 学习阶段都会碰到的问题。
很多回答会从语法、继承、默认实现这些点切入，这些都没错。但 2017 年我在项目里慢慢形成的判断是：真正决定选择的，常常不是当前写起来哪个方便，而是未来变化会往哪个方向长。

Java 8 刚出来那阵，很多人讨论接口默认方法，讨论点常常是“它是不是打破了接口的纯粹性”。我后来在项目里真正用过几次后，反而觉得更实际的问题是：哪些重复代码适合放进去，哪些不适合。

图片上传这类接口最容易在需求讨论里被说成一句话：选文件，传上去，返回地址。
可 2016 年我在做这类功能时越来越明显地感觉到，一个上传接口如果一开始只关注“体验顺不顺”，却没有先限制大小、类型和错误边界，后面出问题会非常频繁。