接口划清能力契约边界，定义“能做什么”；抽象类划清继承体系边界，定义“如何组织自己”；二者协同才能守住业务逻辑完整边界。
接口和抽象类不是用来“堆功能”的，而是帮你把业务逻辑的边界划清楚。关键不在语法怎么写，而在你心里先想明白：哪部分是“必须对外承诺的能力”，哪部分是“内部可复用的骨架”。
接口划清能力契约的边界
接口定义的是“别人能拿它做什么”，不是“它自己怎么做”。比如物流系统里有个 GPS 接口，只声明 getLatitude() 和 getLongitude() 两个方法——这表示：只要实现了它，调用方就一定能拿到坐标，至于是通过北斗模块、高德API还是模拟数据，完全不关心。
这种边界一旦定下，后续扩展就不会牵连业务主流程：
- 新增一个车载GPS设备，只需新写一个实现类，不改任何已有代码
- 测试时可以用MockGPS快速替换真实硬件，不影响SendTask等上层逻辑
- 多个不相关的类（如Truck、Drone、Package）都能实现它，因为坐标能力不绑定具体实体类型
抽象类划清继承体系的边界
抽象类定义的是“这一类东西该怎么组织自己”。比如所有运输工具都得有编号、负责人、保养记录，但“怎么保养”“怎么定位”各不相同。这时用 Transportation 抽象类，把共用字段和通用流程（如统一校验出发时间）写进去，把差异点（如startEngine()）留成抽象方法。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
这个边界意味着：
- 子类必须属于同一语义层级（都是“可调度的运载单元”），不能随便塞进无关类型
- 父类可以控制初始化顺序、模板方法执行流程，比如强制先做安全检查再发车
- 如果某天要加一个“是否支持夜间运输”的字段，加在抽象类里，所有子类自动拥有
两者配合才能守住完整边界
单独用接口，容易变成一堆零散方法，缺乏上下文约束；单独用抽象类，又容易把不该耦合的逻辑硬绑在一起。真实项目里它们是搭档：
- 让 Truck 同时继承
Transportation抽象类 + 实现Careable、GPS等接口 -
Transportation负责“运输这件事怎么结构化”，Careable负责“保养这件事怎么被调用”，GPS负责“定位这件事怎么被获取” - 业务代码里操作的是接口类型（如
List<GPS>），运行时才决定是Truck还是Drone提供坐标
边界模糊时的判断信号
当不确定该用哪个，看这几个信号：
- 想让不同类族（比如车辆和无人机）都具备某能力 → 选接口
- 想强制子类共享字段、构造逻辑或执行流程 → 选抽象类
- 发现抽象类里90%方法都是abstract，只剩一个空构造器 → 其实该用接口
- 接口里default方法越来越多，开始处理状态或调用私有辅助逻辑 → 可能该拆出抽象类了
