接口命名应体现能力而非实现，如drawable、sortable；方法需单一职责且无状态；优先组合小接口而非大而全；谨慎使用常量和default方法以保障兼容性。
接口命名要体现能力而非实现
Java接口名应该描述“能做什么”，而不是“怎么做的”或“谁来做的”。比如用 Drawable 而不是 ShapeRenderer，用 Sortable 而不是 QuickSortAdapter。这样后续可以自由替换实现，而不影响调用方理解。
常见错误是把接口名写成具体类的抽象版，比如 UserServiceInterface——后缀 Interface 是冗余的，且暴露了“这是个接口”的实现细节；UserManager 听起来像具体类，也不适合当接口名。
- ✅ 推荐：
Authenticator、Persistable、Comparable - ❌ 避免：
IAuth（C#风格）、UserDAO（暗示JDBC实现）、JsonSerializable（绑定JSON格式）
接口方法应遵循单一职责且无状态
一个接口里的每个方法都该服务于同一抽象能力。如果发现某个实现类只重写了其中 1–2 个方法，其余抛 UnsupportedOperationException，说明接口职责过宽，该拆分。
接口方法默认是 public abstract，不能有字段（除 public static final 常量），也不能有构造器或实例初始化块。Java 8+ 允许 default 和 static 方法，但要谨慎使用：
立即学习“Java免费学习笔记（深入）”；
-
default方法适合提供通用、非核心的辅助逻辑（如Collections.sort()的替代封装），别用来绕过继承或掩盖设计缺陷 - 避免在
default方法里访问实现类私有状态——它无法访问this的非公开成员 - 多个
default方法若存在冲突（如两个父接口提供同签名方法），编译会报错，必须由实现类显式覆写
优先组合小接口，而非定义大而全的接口
像 java.util.List 这种包含 25+ 方法的接口，对轻量级实现（如只读视图）非常不友好。实际开发中更推荐类似 Iterable + Collection + List 的分层设计：底层接口极简，上层叠加行为。
例如日志场景，与其定义一个 Logger 接口囊括 logInfo()、logError()、setLevel()、addAppender()，不如拆成：
-
Loggable（仅log(Level, String)） -
LogLevelControl（仅setLevel()） -
AppenderAware（仅addAppender()）
这样测试桩、装饰器、代理类可以按需实现，不会被迫实现一堆空方法。
谨慎对待接口中的常量和 default 方法的版本兼容性
接口里声明的 public static final 字段会被所有实现类直接继承，一旦修改值（比如把 TIMEOUT_MS = 5000 改成 3000），不重新编译实现模块，运行时仍用旧值——因为常量在编译期被内联了。
default 方法看似安全，但新增后可能破坏已有实现的行为语义。例如老实现类依赖“未实现即报错”，你加了个 default 方法返回 null，调用方突然收到 NullPointerException 就很难追溯。
所以接口升级时：
- 常量尽量用枚举或配置类替代，避免硬编码值
- 新增
default方法前，先确认是否真有必要；比起加 default，有时提供工具类（如Loggers）更清晰 - 对外发布的接口，一旦发布就尽量不动签名——哪怕加个
default方法，也属于二进制不兼容变更
接口不是越多越好，也不是越“完备”越好。最难的部分，往往不是写代码，而是判断哪个行为该放进接口、哪个该留给实现者自己决定。
