接口是定义契约的工具，核心在于声明“能做什么”而非“怎么做”，应小而专注、命名体现能力、default方法需克制使用。
接口是为了定义契约，不是为了写实现
Java 接口的核心作用是声明“能做什么”，而不是“怎么做”。它强制实现类提供一组指定行为的定义，把调用方和具体实现隔离开。比如你写一个 PaymentProcessor 接口，只声明 process(double amount) 和 refund(long transactionId)，至于走支付宝、微信还是模拟支付，调用方完全不用关心。
常见误用是把接口当抽象类用：在接口里塞默认方法做通用逻辑、甚至加静态工具方法——这模糊了“契约”和“复用”的边界，后续替换实现或 mock 测试时反而更麻烦。
接口应该小而专注，别堆功能
一个接口如果超过 5 个方法，大概率职责过重。比如 UserService 同时包含 create()、sendEmail()、logActivity()、generateReport()，实际使用中，注册流程只需要创建用户和发邮件，却被迫实现日志和报表逻辑。
更合理的做法是拆成：
立即学习“Java免费学习笔记（深入）”；
-
UserCreationService（只含create()） -
EmailSender（只含send()） -
ActivityLogger（只含log()）
这样每个实现类职责清晰，单元测试容易覆盖，也方便按需组合（比如测试时用 MockEmailSender 替换真实发送器）。
接口名要体现能力，别用 “Impl” 或 “Manager”
命名直接影响可读性和扩展性。FileManager 这种名字隐含了“管理文件”的动作，但没说清它到底提供什么能力；FileReader 和 FileWriter 就更直接——一看就知道能读、能写。
避免这些命名习惯：
-
UserServiceImpl（这是实现类名，不是接口） -
DataManager（太泛，无法推断 contract） -
IUserDao（I前缀是 C# 风格，在 Java 中不必要且干扰阅读）
优先选动宾结构：Authenticator、OrderValidator、CacheEvictor——它们天然表达“这个东西能干什么”。
default 方法要用得克制，别破坏接口的纯粹性
Java 8 引入 default 方法本意是向后兼容（比如给 Collection 加 stream()），不是让你把工具逻辑塞进接口。一旦接口里出现多个 default 方法，尤其是相互调用或依赖外部类，它就开始偏离“契约”定位，变成半抽象类。
判断是否该用 default 的简单标准：
- 该逻辑是否对所有实现都通用？（比如
List.sort()基于Comparable的默认排序） - 有没有状态依赖？（有就别放 default，接口不该持状态）
- 能不能用组合替代？（例如把通用逻辑抽成
ValidationHelper，让实现类注入使用）
真正难处理的是那些“几乎总是相同，但偶尔要定制”的逻辑——这时候宁可多写一行实现，也比在接口里埋一个看似方便、实则难以 override 的 default 方法强。
