接口是定义契约的工具，核心在于声明“能做什么”而非“怎么做”，应小而专注、命名体现能力、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 就更直接——一看就知道能读、能写。
