Java委派机制：对象协作新方法

Java委派机制是一种基于组合、接口与运行时动态选择的对象协作范式，它以“uses-a”关系替代继承的“is-a”关系，提供更灵活、低耦合、易测试的代码组织方式；文章深入剖析了委派的适用场景、典型误用（如硬编码实例化）、与代理/策略模式的本质区别，并强调其核心挑战不在于语法实现，而在于职责边界的清醒判断——避免委派类异化为臃肿的上帝类，真正让每个对象各司其职、协同有度。

Java中的委派不是语法特性，而是一种靠组合+接口+运行时选择实现的对象协作方式——它不靠 extends，而是让一个对象“请”另一个对象干活。

什么时候该用委派，而不是继承？

当你想复用某类逻辑，但又不想暴露它的全部 API、也不愿被它的父类约束时，委派就是更干净的选择。比如你有个 FileProcessor 类封装了读写逻辑，但你不希望业务类成为它的子类（否则得重写一堆钩子方法），这时就该把它作为字段持有并转发调用。

• 继承适用于「is-a」关系（Car extends Vehicle），委派适用于「uses-a」或「has-a」关系（ReportGenerator uses PDFExporter）
• 继承在编译期绑定，改父类可能破坏子类；委派在运行时决定委托对象，可动态替换（比如根据配置切换 CloudStorage 或 LocalStorage）
• 继承容易导致类层次过深，委派天然扁平——一个类可以同时委派给多个不同职责的对象

TaskDelegate 这类典型写法为什么容易出错？

很多教程直接在 doTask() 里 new 具体实现类，看似简单，实则埋雷：每次调用都新建实例，无法复用状态、无法注入依赖、无法做单元测试 mock。

• 错误写法：task = new ConcreteTaskA(); —— 硬编码、不可测、生命周期失控
• 正确做法：通过构造器或 setter 注入 Task 实例，或者用工厂/ServiceLoader 解耦创建逻辑
• 若需策略切换（如按用户角色选处理器），别用 Random 或硬写 if-else，改用 Map 查表，或结合 Spring 的 @Qualifier 自动装配

委派和代理（Proxy）、策略（Strategy）怎么分清？

三者代码结构有时相似，但意图完全不同：委派关注「谁来执行」，代理关注「执行前后加控制」，策略关注「算法可替换」。

• 委派类（TaskDelegate）通常不改写行为，只是路由请求——它自己不实现业务，只做中转
• 代理类（如 JDK 动态代理）必须实现相同接口，但会在调用前后插入日志、事务、权限等横切逻辑
• 策略类（PaymentStrategy）强调算法族的统一抽象，客户端明确选择并持有某一种，不负责决策逻辑
• 一个类可以同时是委派者 + 代理者（比如先委派给具体实现，再由代理包装其调用），但不能混淆设计意图

真正难的不是写对委派结构，而是判断「这个职责到底该由谁拥有」。很多人把本该属于领域对象的逻辑塞进委派类，结果委派类越来越胖，成了新的上帝类——这时候就得停下来，重新划清边界。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java委派机制：对象协作新方法》文章吧，也可关注golang学习网公众号了解相关技术文章。