Java接口作方法形参本质是分离“做什么”与“怎么做”，调用方只依赖行为契约，不耦合具体实现，从而提升可替换性、可测试性与扩展性。
用Java接口作方法形参，本质是把“做什么”和“怎么做”彻底分开——调用方只关心接口定义的行为契约，不依赖具体实现类。这正是面向接口编程的核心：降低耦合、提升可替换性与可测试性。
定义清晰、聚焦的业务接口
接口不是对已有类的简单抽象，而是从业务语义出发设计的契约。比如订单处理场景，不要定义一个大而全的 OrderService，而应拆解为：
-
PaymentProcessor：只管“完成支付”，方法如process(PaymentRequest req) -
InventoryLocker：只管“锁定库存”，方法如lock(ItemId item, int quantity) -
NotificationSender：只管“发送通知”，方法如send(Alert alert)
每个接口职责单一、方法语义明确，便于组合与替换，也利于单元测试时用模拟实现（Mock）隔离依赖。
方法签名中直接使用接口类型
形参类型必须是接口，而非其实现类或 Object。例如：
立即学习“Java免费学习笔记（深入）”；
public class OrderExecutor {
// ✅ 正确：形参是接口，调用方传任意符合契约的实现
public void executeOrder(PaymentProcessor payer,
InventoryLocker locker,
NotificationSender notifier) {
locker.lock(...);
payer.process(...);
notifier.send(...);
}
}
这样写，方法本身不 new 任何实现类，也不 import 具体实现包，完全不感知底层是支付宝、微信还是模拟支付；是 Redis 锁还是数据库锁；是短信、邮件还是站内信。
运行时注入具体实现，而非编译期绑定
实现类的创建和传递，交给外部控制（如 Spring 的 @Autowired、手动工厂、或构造器注入），避免在业务方法内部 new XxxImpl()。
- Spring 环境下，用
@Service标记实现类，接口类型自动注入 - 无框架时，可通过构造器传入：
new OrderExecutor(new AlipayProcessor(), new RedisLocker(), new SmsSender()) - 测试时，直接传入轻量模拟对象：
executeOrder(new MockPayment(), new InMemoryLocker(), new StubNotifier())
关键点：谁创建、谁决定用哪个实现——这个决策权必须从核心逻辑中移出。
配合策略模式或模板方法，让接口成为扩展点
当同一行为有多种算法（如不同风控规则、不同运费计算方式），可将策略接口作为形参，使主流程保持稳定：
public void calculateFee(Order order, FeeCalculator calculator) {
BigDecimal fee = calculator.calculate(order); // 具体怎么算，由传入的 calculator 决定
order.setFee(fee);
}
新增一种计费方式，只需新增一个 FeeCalculator 实现类，无需修改 calculateFee 方法——这就是开闭原则的落地。
不复杂但容易忽略：接口命名要动词化或角色化（如 Validator、Exporter），方法名要体现意图（validate()、exportToCsv()），而不是技术细节（doCheck()、handle()）。契约越干净，面向接口才越自然。
