Java设计模式高度依赖面向对象，因其本质是系统性复用封装、继承、多态、抽象四大特性：多态支撑开闭原则与可插拔扩展，抽象与封装划定变化边界，继承与组合构建可生长结构，而函数式或过程式无法自然表达OOP语义下的角色与状态委托关系。
Java里的设计模式之所以高度依赖面向对象（OOP），根本原因在于：设计模式本质是**对OOP四大特性（封装、继承、多态、抽象）的系统性复用**，它们不是凭空而来的技巧，而是为解决OOP语境下典型的扩展性、解耦与复用问题所沉淀出的结构化方案。
多态：让“变化的部分”可插拔
扩展性最核心的挑战，是新增功能不改旧代码。这直接靠多态支撑——父类或接口定义行为契约，子类自由实现。比如策略模式中，不同算法封装成独立类，通过统一接口注入上下文；添加新策略只需新增一个实现类，完全不影响原有逻辑。
- 没有多态，就得用if-else硬编码判断类型，每次加新行为都要动主流程
- 接口+重写方法+运行时绑定，才是“开闭原则”的落地基础
抽象与封装：划清扩展边界
设计模式普遍通过抽象类或接口隔离变化点，把“什么要变”和“怎么变”分开。例如模板方法模式，把算法骨架定义在抽象类中，把可变步骤声明为abstract或hook方法；子类只专注实现差异部分，骨架逻辑零修改。
- 封装隐藏了具体实现细节，使用者只依赖抽象——这正是扩展的前提：你换实现，我不受影响
- 抽象层本身不包含业务逻辑，却规定了扩展必须遵循的结构，避免随意蔓延
继承与组合：构建可生长的结构
继承用于表达“is-a”关系下的能力复用（如工厂方法中，子类继承父类并重写创建方法）；组合则更灵活地拼装行为（如装饰器模式，动态叠加功能）。二者配合，让系统像搭积木一样延展。
立即学习“Java免费学习笔记（深入）”；
- 纯继承易导致类爆炸，组合+接口才真正支撑“小步快跑式扩展”
- 观察者、责任链等模式，本质上都是通过对象间松耦合引用，形成可动态增删的运行时结构
为什么不是函数式或过程式？
Java的设计模式生态扎根于OOP语义：类作为模块单元、实例承载状态、方法调用隐含接收者。若脱离类体系，单靠静态方法或函数闭包，就难以自然表达“谁拥有状态”“谁响应消息”“谁决定委托给谁”这些关键扩展决策点。模式中的“角色”（如Subject、Handler、Product）本身就是OOP建模的产物。
不复杂但容易忽略：设计模式不是炫技，是把OOP的潜力用标准方式拧紧——理解它，就是理解Java程序如何真正活起来、长出来。
