继承曾经是Java世界最引以为傲的复用武器如今却成了无数项目腐化的温床。当你写下extends关键字时你不仅继承了父类的字段和方法还继承了它的全部秘密——私有状态可以通过受保护方法间接影响、子类方法的调用时机被父类构造器悄悄劫持、未来任何看似无关的父类修改都可能让你的子类在运行时炸开。继承是面向对象中最危险的亲密关系它把复用变成了对父类实现细节的押注。很多团队痴迷于“BaseService”、“AbstractHandler”这样的基类设计试图用一层层的抽象把公共逻辑抽出来。开始时一切美好公共代码确实被复用了但几个月后基类膨胀到几百行子类里塞满了Override空实现来跳过不想用的逻辑或者用super方法内部的一堆if (this instanceof ...)来区分行为。这就是白盒复用的代价你复用的不是接口契约而是某个人在某个深夜写下的具体大括号里的语句。Java的继承体系让子类与父类形成编译期绑定这种绑定如此紧密以至于连Liskov替换原则都无法拯救它——因为你根本不清楚父类到底承诺过什么。换成组合呢组合的核心理念是“持有”而不是“替代”。你不需要继承一个AbstractNotificationSender而是构造一个NotificationService让它持有MessageSender、Logger、MetricsRecorder这些独立组件。每个组件都是黑盒通过接口暴露行为。调用方只需要知道接口方法签名至于消息是走短信、邮件还是Kafka那是实现类自己的事。组合把复用从“我是谁”变成“我和谁协作”把“代码血统”变成“对象关系图”。这种黑盒复用的最大优势是你可以替换、装饰、拦截组件而不必触碰调用方代码更不必担心父类内部某个私有状态没有初始化。有人会问难道Java接口就不重要了恰恰相反接口是组合得以实现的地基。没有接口组合就是拿着一堆具体类硬拼耦合依旧。但接口的粒度设计才是关键——你不需要设计一个包罗万象的巨型接口而是要围绕“角色”来定义。比如Readable、Writable、Comparable每一个都代表一种能力而不是一个实体。当UserService组合了UserValidator、UserRepository、EventPublisher三个接口时它复用的不是“用户类的某个版本”而是“校验逻辑、存储逻辑、通知逻辑”各自独立的演进单元。这就是接口隔离原则在组合里真正的落地组合是接口的织布机继承是类之间的锁链。实践中最常见的组合姿势是构造函数注入。一个服务类把依赖作为构造参数传入而不是在内部new出来。这让复用对象的创建权完全交出去——单元测试时注入Mock生产环境注入真实实现两全其美。Spring的依赖注入容器更是把组合推向极致Component标注的类被容器拼装成对象图生命周期由容器管理。但请注意容器让你摆脱了new的繁琐却也让你误以为组合不需要思考。当你往一个类里注入七八个依赖时这个类本身已经变成了缝合怪。组合不是越多越好它要求你对“复用边界”有清醒的认知哪些组件是内聚的能力哪些是偶然的公共代码。继承的临时逃生口是接口默认方法。Java 8之后你可以在接口里写default实现这看起来像是“两全其美”——既定义了契约又提供了公共逻辑。但默认方法是一剂鸦片它让接口变成了隐形的抽象类。一旦你给接口加上默认方法所有实现类都悄悄“继承”了这段代码如果默认方法内部引用了其他接口方法你就无法保证实现类是否以你预期的方式实现了它们。更糟的是默认方法无法声明受保护成员无法持有实例字段它试图模拟继承却又残缺不全。组合面前默认方法适合做兼容层比如给旧接口加新方法时提供兜底实现而不是用它来搭公共逻辑的主干。说回继承的经典场景模板方法模式。父类定义算法骨架子类重写某些步骤。这种复用确实优雅尤其在算法流程固定且变化点明确时。但问题在于模板方法模式把“算法流程”和“步骤实现”绑定在同一继承树上。如果另一个算法也想复用同样的步骤你会陷入多重继承的泥潭——Java不支持于是你只能把步骤上提让父类更臃肿。改用组合的模式是策略模式把每个步骤封装为独立的策略接口算法类持有这些策略。模板方法用继承锁定流程策略模式用组合开放步骤。当你的算法有10种变化而每个步骤有3种实现时继承需要30个类组合只需要3个策略接口、10个具体策略类和一个算法协调器。哪个更灵活一目了然。还有装饰器模式更是组合的杰作。BufferedInputStream并不继承FileInputStream它只是持有一个InputStream在调用read之前做缓冲再委托给被装饰者。装饰器用组合实现了无限层级的动态复用而继承只能做有限且静态的扩展。如果你试图用继承实现缓冲、加密、压缩、行号跟踪的任意组合类的数量会爆炸到没有人敢维护。装饰器让代码复用变得像乐高积木每一个装饰器只做一件事但它可以包在任何流上面。这正是“组合优于继承”的最直观证明继承是给类做乘法组合是给对象做加法。但组合也有它的代价。对象之间通过引用彼此联系关系网复杂后阅读代码时你需要追踪多个对象的创建和交互。调试时调用栈可能横跨五六个对象每个对象都只是转调。这种“过度委托”反噬时的痛苦不亚于继承体系的“上帝基类”。组合的失败模式是“碎成渣”类多得像米粒功能散得找不到北。所以业界有了先聚合成类再对类做组合的建议——先保证单个类的高内聚再用组合拼装高内聚的类。而不是把类的每个方法都剥离成独立的“组件”来追求所谓复用。复用单位应该是“完备的职责”不是“单行的方法”。现代Java正在向更轻量的组合迈进。记录类Record、模式匹配、密封接口让数据和行为分离得更彻底。MapStruct用编译期代码生成替代了手写getter/setter的“数据拷贝复用”Quarkus和Micronaut的构建时AOP把横切逻辑生成字节码注入物理上减少了运行时的动态代理对象。这些都是组合思想的升华复用不再依赖运行时继承而是在编译期就计算出最优对象结构。比如用//标签处理器组装记录用Function组合替代模板方法你甚至不再需要extends关键字只要record和接口就能描述大部分业务逻辑。回到本质继承和组合是两种不同的思维模式。继承是“我从你那里来”组合是“我需要你的能力”。代码复用真正的敌人不是继承本身而是不加思考的复用冲动。如果一个类确实与另一个类构成“is-a”关系且父类永远不会被修改、子类永远不会重写非抽象方法、不需要多态扩展那么继承完全合理——比如HashMap继承AbstractMap。但现实是这种理想情况极少。绝大多数“复用”只是“我想用这个方法”那就用组合——把它拆出来做成Component或FunctionalInterface然后在需要的地方持有它。当你下次忍不住想写extends时先问自己你是在表达“我是你”还是仅仅在偷懒地借用代码这个问题比任何设计模式都更能检验你的架构品味。