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