为Java类添加打印功能的正确实现方式是什么？

现有方案优劣分析 #

• 方案1：直接在Report类中新增成员和方法
  适用场景：所有Report实例都需要打印能力，且后续不会出现不需要打印的Report派生类。
  优势：实现成本最低，无额外层级，原有Report的调用逻辑不需要做任何修改。
  劣势：违反单一职责原则，将打印逻辑和Report核心业务逻辑耦合，后续如果新增导出、归档等附加能力会导致Report类持续膨胀，不需要打印的使用场景也会被迫引入GeneralPrinter、LanguageTranslator等冗余依赖。
• 方案2：派生PrintableReport子类实现
  适用场景：仅部分Report实例需要打印能力，且后续附加能力的扩展需求极少。
  优势：保留了原有Report类的纯净，不需要打印的场景可以继续使用原生类，无冗余依赖。
  劣势：如果后续需要新增多种附加能力，会出现类爆炸问题，要支持多种能力组合的场景还需要处理多重继承的问题，维护成本会快速上升。
• 方案3：装饰器模式实现
  该场景完全适配装饰器模式，不存在用法错误的问题。
  适用场景：打印为可选附加能力，后续可能新增其他附加能力，或存在多种能力组合使用的需求。
  优势：完全符合开闭原则，不需要修改原有Report类，打印逻辑和核心业务逻辑完全解耦，新增附加能力只要开发对应的装饰器即可，支持灵活组合多类能力。
  劣势：实现复杂度略高于前两种方案，调用方需要对原Report实例做装饰器包装才能使用打印能力。

其他可选方案 #

可以采用服务类分离方案：完全不把打印逻辑耦合进Report类体系，单独实现ReportPrintService服务类，打印相关的逻辑、优化缓存成员都放在服务类中，执行打印时将Report实例、GeneralPrinter、LanguageTranslator作为参数传入服务类方法即可。该方案适合打印逻辑迭代频率远高于Report核心逻辑的场景，完全隔离两类逻辑的变更影响。

最优选择建议 #

没有通用最优解，根据业务场景匹配即可：

1. 全量Report都需要打印、后续无其他附加能力扩展计划，选方案1，投入最小效率最高。
2. 仅部分Report需要打印、附加能力扩展需求少，选方案2。
3. 后续扩展可能性高、需要灵活组合多种附加能力，选方案3，长期维护成本最低。
4. 打印逻辑复杂、迭代频率高，选服务类分离方案。

内容的提问来源于stack exchange，提问作者A.Hristov