设计模式：开闭原则-CSDN博客

想象你的房子🏠和它的扩展方式：

“修改关闭”的墙（核心系统）：
- 你房子的承重墙是建好的，结构稳固。你不能为了加个新房间，就去砸掉或者改动这些承重墙（修改原有代码）。
- 改动承重墙风险巨大（系统崩溃）、成本高昂（测试、修复BUG）、影响整个房子的稳定（破坏现有功能）。
“扩展开放”的门窗与接口（可扩展设计）：
- 但是，你的房子在设计时预留了可能性：
  - 预留的门窗位置： 就像系统里定义好的接口(Interface) 或抽象类(Abstract Class)。它们规定了新房间（新功能）如何接入房子（系统）。
  - 水电煤接口： 就像系统提供的扩展点或回调机制。新房间只要按照标准接口接上水电煤（实现接口、继承抽象类），就能正常使用。
- 想加个阳光房？☀️ (新功能 - 比如折线图)
  - 不需要砸承重墙！ (不修改现有核心代码)
  - 你只需要：在预留的位置，按照标准门窗尺寸建一个新的阳光房（创建一个新的LineChart类，实现AbstractChart接口或继承AbstractChart类）。
  - 然后，把这个新房间接入预留的水电煤接口（在客户端代码里，比如配置文件或初始化时，告诉系统ChartDisplay现在可以用LineChart了）。
  - 阳光房建好了，功能完整，完全不影响原来的客厅、卧室（原有的饼图、柱状图功能）。
配置文件 - 神奇的“开关面板”🔌：
- 决定用哪个房间（显示哪个图表）可以通过一个开关面板（配置文件：XML, properties, JSON等）来控制。
- 想换阳光房显示？不用重新布线（改代码），只需在开关面板上按一下（修改配置文件里的一个值，比如chart.type=line）。
- 这不算“修改房子结构”（修改源代码），只是改变了设置。

所以，开闭原则 (OCP) 的核心思想就是：

“关”： 核心系统结构要稳如泰山，已有的、运行良好的代码尽量别动（对修改关闭）。动它们风险高、容易出错。
“开”： 要拥抱变化，轻松加新功能（对扩展开放）。通过提前设计好的接口、抽象和扩展点，让新功能像乐高积木一样，“咔哒”一声就能插进系统，不需要动原来的积木。
“配置即扩展”： 很多时候，通过简单的修改配置文件来启用新功能，是最符合OCP精神的做法，因为这完全避免了修改编译过的代码。

初始设计 (违背 OCP)： 想加折线图？必须砸墙—— 打开ChartDisplay类的代码，修改display()方法，硬塞进去一段else if (type.equals("line"))...。这风险大，容易把原来的饼图、柱状图逻辑改坏。
重构后 (遵循 OCP)：
- “承重墙” (稳定的抽象)： AbstractChart 接口或抽象类。ChartDisplay只依赖它，不关心具体是什么图。
- “预留门窗/接口”： AbstractChart 定义了display()方法这个标准接口。
- “加阳光房” (扩展)： 创建LineChart，实现AbstractChart的display()方法。
- “接入系统” (配置/注入)： 在客户端代码或配置文件中，告诉ChartDisplay：这次请用LineChart对象 (setChart(new LineChart()) 或配置 chart.class=com.example.LineChart)。
- “开关面板” (配置文件)： 改一下配置文件里的图表类型，系统就自动显示折线图了，一行核心代码都不用改。