Java里把一个方法的形参类型写成接口或者父类，调用时却传入具体的实现类或子类对象，这是多态最直接的落地方式。方法签名看似固定，传入对象的真实类型却在运行时决定哪段代码被执行。这个机制依赖两个动作：调用前的向上转型，以及方法调用时的动态绑定。
向上转型发生在参数传递的瞬间。例如方法声明为paint(Shape shape)，调用方传入new Circle(2.0)，编译器会先把Circle引用隐式转换成Shape引用，再交给方法。这个过程不需要显式类型转换，因为Circle实现了Shape接口，编译器认为这种赋值是安全的。向上转型之后，引用变量在编译期只能访问Shape定义的方法，但运行时会根据实际对象类型分派到Circle或Square的实现。
一、多态参数的本质：向上转型与动态绑定
Java里当方法形参类型是接口或父类时，编译器只检查传入对象是否属于该类型或其子类型。比如paint(Shape shape)方法，调用时写paint(new Circle(2.0))，编译器先把Circle引用向上转型为Shape，再把引用交给方法。这个过程是隐式的，不需要显式类型转换。向上转型之后，引用变量在编译期只能看到Shape定义的方法，但运行时会根据实际对象类型分派到Circle或Square的实现。
这里的关键是动态绑定。普通方法调用在字节码层面使用invokevirtual指令，虚拟机不会根据引用类型决定目标方法，而是根据对象头中的类元数据查找实际方法。因此即使形参声明为接口Shape，执行shape.area()时也会调用真实对象的area()。理解这一点可以避免一个常见误解：多态参数并不是把对象转换成父类后丢失行为，而是把编译期可见范围收窄到接口契约。
interface Shape {
double area();
}
class Circle implements Shape {
private double r;
public Circle(double r) {
this.r = r;
}
@Override
public double area() {
return Math.PI * r * r;
}
}
class Square implements Shape {
private double side;
public Square(double side) {
this.side = side;
}
@Override
public double area() {
return side * side;
}
}
class Painter {
public void paint(Shape shape) {
System.out.println("面积：" + shape.area());
}
}
public class Main {
public static void main(String[] args) {
Painter painter = new Painter();
painter.paint(new Circle(2.0));
painter.paint(new Square(3.0));
}
}
上面代码中Painter完全没有依赖Circle和Square，未来增加Triangle只要实现Shape接口，Painter的paint方法一行都不用改。这就是多态参数在代码层面带来的直接收益：调用方与实现解耦，方法体只面向抽象。
二、接口形参的典型使用场景
支付场景最能体现接口形参的价值。订单服务如果直接依赖支付宝或微信支付的类，每次新增支付渠道都要改动订单服务，系统会变得越来越脆弱。把参数类型抽象成Payment接口后，OrderService只调用pay方法，具体扣款逻辑由实现类负责。
import java.math.BigDecimal;
interface Payment {
void pay(BigDecimal amount);
}
class Alipay implements Payment {
@Override
public void pay(BigDecimal amount) {
System.out.println("支付宝扣款：" + amount);
}
}
class WechatPay implements Payment {
@Override
public void pay(BigDecimal amount) {
System.out.println("微信支付扣款：" + amount);
}
}
class OrderService {
public void createOrder(Payment payment, BigDecimal amount) {
payment.pay(amount);
}
}
这个例子中OrderService.createOrder接收Payment接口，不关心传入的是Alipay还是WechatPay。如果想增加银行卡支付，只需新增BankCardPayment实现Payment接口，订单服务无需修改。这种设计就是依赖倒置原则的基础：高层模块不依赖低层模块，二者都依赖抽象。
接口形参还特别适合测试场景。单元测试可以传一个MockPayment，记录支付调用参数并返回预设结果，不需要真实连接支付网关。生产代码和测试代码面对同一个方法签名，这是接口作为形参带来的可替换性。
三、父类形参与接口形参如何选择
接口用来定义行为规范，父类则可以同时提供公共状态和默认实现。比如Animal抽象类里有name字段和构造器，eat方法留给子类实现。Feeder.feed(Animal animal)使用父类形参，既可以接收Dog，也可以接收Cat。相比接口，父类形参的好处是方法内部可以直接使用父类定义的公共成员。
abstract class Animal {
protected String name;
public Animal(String name) {
this.name = name;
}
public abstract void eat();
}
class Dog extends Animal {
public Dog(String name) {
super(name);
}
@Override
public void eat() {
System.out.println(name + " 啃骨头");
}
}
class Cat extends Animal {
public Cat(String name) {
super(name);
}
@Override
public void eat() {
System.out.println(name + " 吃鱼");
}
}
class Feeder {
public void feed(Animal animal) {
animal.eat();
}
}
不过父类形参也有局限。Java只支持单继承，如果一个类已经继承了某个父类，就无法再继承Animal。此时接口形参的灵活性更高。一般来说，如果多个类只是表现出相同行为但内部结构差异很大，优先接口；如果它们天然属于同一族类，并且需要复用父类字段或方法，才可以考虑抽象父类。
还有一种混合思路：接口定义核心契约，抽象父类提供骨架实现。方法形参仍然使用接口，这样既能复用骨架实现，又不会把参数类型限定在某个父类之下。例如定义Payment接口、AbstractPayment提供日志和重试，Alipay继承AbstractPayment并实现Payment。调用方仍声明pay(Payment payment)，可以获得最大灵活度。
四、使用多态参数时的常见误区
第一个误区是在方法内部大量使用instanceof和向下转型。比如handle(Animal animal)方法里判断animal instanceof Dog，强转为Dog后调用看门方法，再判断Cat调抓老鼠。每次新增动物都要修改这个方法，说明多态并没有真正发挥作用。正确做法是把差异化行为抽象成方法，由子类各自实现。
public void handle(Animal animal) {
if (animal instanceof Dog) {
Dog dog = (Dog) animal;
dog.watchDoor();
} else if (animal instanceof Cat) {
Cat cat = (Cat) animal;
cat.catchMouse();
}
}
第二个误区是参数类型定义得过于宽泛。用Object作为形参虽然能接收任何对象，但方法内部必须做类型判断和转换，几乎失去了编译期检查能力。除非真的需要处理完全不相关类型的公共逻辑，否则不要用Object替代接口或父类。
第三个误区是误以为多态参数会带来严重性能损耗。动态分派确实比静态调用多一次方法查找，但现代JVM会通过内联缓存等手段将开销降到极低，通常不会成为系统瓶颈。相比可维护性的提升，这点成本几乎可以忽略。
最后还要注意空值处理。多态参数传入null时，如果方法直接调用接口方法会抛出NullPointerException。可以在入口处校验，或者使用明确的设计约束避免null传播到核心逻辑。参数类型越抽象，越要明确它在方法中的契约边界。