UML类图
一、UML类图核心关系详解
UML类图是面向对象设计的“语言”，通过不同的箭头符号，清晰表达类与类之间的交互逻辑，是理解设计原则的基础。
- 关联关系
类与类之间存在长期的、结构性的联系，比如“用户和订单”，一个用户可以有多个订单，这种稳定的使用关系就是关联。关联可以是单向的（A知道B），也可以是双向的（A和B互相知道），在代码中通常表现为类的成员变量引用。 - 聚合关系
是一种特殊的关联，代表“整体-部分”的弱依赖关系。部分可以脱离整体独立存在，比如“班级和学生”，班级解散了，学生依然存在。聚合关系强调“has-a”，整体不负责部分的生命周期管理。 - 组合关系
是比聚合更强的“整体-部分”关系，部分无法脱离整体存在，整体消失时部分也随之消失，比如“人和心脏”。组合关系强调“contains-a”，整体完全负责部分的生命周期管理。 - 依赖关系
是类之间临时的、非结构性的使用关系，比如A类的方法参数、局部变量中用到了B类，用完即走，不形成长期联系。依赖关系是类之间最松散的耦合形式。 - 泛化关系（继承）
代表子类与父类的关系，子类继承父类的属性和方法，也可以重写父类方法，体现“is-a”的关系。泛化是面向对象实现代码复用的重要方式。 - 实现关系
代表类与接口的关系，类实现接口中定义的所有方法，从而承诺提供接口约定的行为。实现关系是解耦的关键，通过接口隔离，让类仅依赖抽象，而非具体实现。
二、单一职责原则（SRP）
核心定义：一个类应该只有一个引起它变化的原因。
简单来说，就是一个类只负责一件事，把一件事做到极致，而不是一个“万能类”。
遵循SRP，我们要把类的职责拆分：界面交互类只负责界面，数据操作类只负责数据查询，数据库连接类只负责连接管理。每个类的职责足够单一，修改一处不会影响其他部分，代码的可维护性和复用性会大幅提升。
三、开闭原则（OCP）
核心定义：软件实体（类、模块、函数）应该对扩展开放，对修改关闭。
也就是说，新增功能时，不要修改原有稳定的代码，而是通过扩展的方式实现新需求。
比如最初的图表显示系统，直接在主类里根据类型判断调用饼图、柱状图的显示方法，每次新增图表类型，都要修改主类的判断逻辑，破坏了原有代码的稳定性。
遵循OCP，我们通过抽象层隔离变化：定义一个通用的图表接口，饼图、柱状图都实现这个接口，主类仅依赖接口调用方法。后续新增折线图、雷达图时，只需要新增一个实现接口的类，无需修改主类的任何代码，既实现了功能扩展，又保证了原有代码的稳定。
