UML类图六种关系详解：继承、实现、依赖、关联、聚合、组合

UML 类图这东西刚入行那会儿我总觉得是“画给领导看的”直到有一次接手一个别人写了半年的模块打开代码一看七八个类互相调用字段传来传去我盯着屏幕愣是没理清谁是谁的爹。后来硬着头皮把类图补了一遍才发现问题根本不在代码写得多烂而在于当初设计的时候类与类之间的关系就没想明白——该用组合的地方用了继承该松耦合的地方搞成了强依赖改一个类牵动一片。从那以后我就认了一个理类图不是文档装饰它是你脑子里那张“谁跟谁什么关系”的地图。这篇内容我打算把 UML 类图里最核心的六种关系——继承、实现、依赖、关联、聚合、组合——从头到尾捋一遍。不是那种教科书式的定义罗列而是结合 Java 代码和类图画法讲清楚每种关系在代码里长什么样、在图上怎么画、什么时候该用哪种、用错了会出什么事。适合刚学面向对象设计的朋友打基础也适合工作几年但一直对“聚合和组合到底差在哪”模棱两可的同行对照着查漏补缺。看完你至少能做到拿到一段 Java 代码能反推出对应的类图关系反过来画类图的时候手不抖知道那根线该画实线还是虚线、该画空心三角还是实心菱形。1. 先把类图这块“地图”的图例认全在聊六种关系之前得先把类图里那些符号认清楚。很多人画类图出问题不是不懂关系而是图例用错了——该用空心三角的地方画了个箭头该用实心菱形的地方画了空心菱形读图的人直接理解反了。所以这一节先把“零件”过一遍后面讲关系的时候才不会卡壳。1.1 一个类在图上到底画几格UML 类图里一个类通常画成一个矩形分成三格。最上面一格写类名中间一格写属性字段最下面一格写方法。属性的一般写法是可见性 名称: 类型方法写成可见性 名称(参数列表): 返回类型。可见性用符号表示是 public-是 private#是 protected~是包级私有。举个具体的例子一个订单类在图上大概长这样------------------ | Order | ------------------ | - orderId: String| | - amount: double | ------------------ | getAmount(): double | | addItem(item: Item): void | ------------------这里有个实操中很容易被忽略的点属性和方法不必全画。类图是沟通工具不是代码镜像。你画一个包含三十个字段的类读图的人眼睛都花了。我的习惯是只画跟当前讨论的关系相关的字段和方法其他的省略。如果确实需要表达“还有别的成员”可以在最后一格写个...表示省略。这一点在团队评审时特别重要图越干净讨论越聚焦。1.2 六种关系对应的线型速查六种关系在图上用的线型、箭头、菱形各不相同这是最容易混淆的地方。我整理了一张对照表建议先扫一眼后面每个关系展开的时候再回来对照关系线型箭头/端点方向语义Java 中的典型体现继承泛化实线空心三角箭头子类指向父类extends实现虚线空心三角箭头实现类指向接口implements依赖虚线普通箭头开口使用者指向被使用者方法参数、局部变量、静态调用关联实线普通箭头可双向持有方指向被持有方成员字段聚合实线空心菱形 普通箭头整体指向部分成员字段弱持有组合实线实心菱形 普通箭头整体指向部分成员字段强持有提示菱形永远画在“整体”那一端箭头指向“部分”。这个方向搞反是新手最常见的错误画反了语义完全颠倒。记住一个口诀继承实现看三角实线继承虚线实现依赖关联看箭头虚线依赖实线关联聚合组合看菱形空心聚合实心组合。这个口诀我当年贴在显示器边上贴了两个月后来就刻进脑子里了。1.3 为什么图例错了比不画还糟我见过一个项目类图里把组合画成了聚合结果新来的同事以为那个部件对象可以从外部传进来复用写了个构造函数注入跑起来各种状态错乱。根因就是图例误导——聚合意味着“部分可以独立存在、可以从外部来”组合意味着“部分的生命周期由整体完全掌控”。一根线的差别背后是对象生命周期管理的根本分歧。所以这一节我想强调的不是“记住符号”而是符号背后对应的是代码里的真实约束。你画图的时候如果对某个关系拿不准别硬画回去看代码里那个字段是怎么初始化的、有没有对外暴露 setter、对象销毁时部分要不要跟着销毁。这些细节决定了你该画哪种线而不是凭感觉挑一个好看的。2. 继承与实现站在“是不是一种”的角度做判断继承和实现在图上都用空心三角区别只在实线和虚线。这两个关系放在一起讲是因为它们回答的是同一类问题“这个类和那个类是不是同一种东西”。继承是“子类是一种父类”实现是“这个类是一种接口所描述的能力”。判断标准清晰了用哪个就不纠结了。2.1 继承is-a 关系的代码落地与类图画法继承在 Java 里就是extends。比如有一个Vehicle类Car继承它语义是“车是一种交通工具”。类图上从Car画一条实线末端空心三角指向Vehicle。public class Vehicle { protected String brand; public void move() { System.out.println(moving); } } public class Car extends Vehicle { private int doorCount; Override public void move() { System.out.println(car moving on road); } }继承的核心价值是复用父类的属性和行为同时允许子类改写。但它也是最容易被滥用的关系。我踩过的一个典型坑早期写业务代码看到两个类有相似字段就想抽个父类结果抽完之后父类越来越臃肿子类被迫继承了一堆自己根本用不上的方法。这就是典型的“为了复用而继承”违反了 is-a 的判断标准——如果子类不能理直气壮地说“我是一种父类”那这个继承就是错的。判断要不要用继承我一般问三个问题第一子类是不是父类的一种特化第二父类的所有行为对子类都成立吗第三子类需不需要改写父类的某些行为三个都答“是”继承才站得住。只要有一个答“否”就该考虑用组合或者接口替代。2.2 实现接口契约与虚线三角的表达实现对应 Java 的implements类图上用虚线加空心三角从实现类指向接口。接口在类图里的画法和类类似但通常会在名称上方标注interface。public interface Payable { void pay(double amount); } public class AlipayPayment implements Payable { Override public void pay(double amount) { System.out.println(paid via alipay: amount); } }实现和继承的本质区别在于继承表达“是什么”实现表达“能做什么”。一个类只能继承一个父类但可以实现多个接口这就是 Java 用接口来规避单继承限制的设计。类图上一个类可以有多条虚线三角指向不同接口读图的人一眼就能看出这个类承担了哪些契约。实操中我有个习惯优先定义接口再考虑抽象类。接口把“能力契约”和“具体实现”彻底分开调用方只依赖接口替换实现的时候一行调用代码都不用改。这也是后面讲依赖倒置的基础。当然如果多个实现类有大量公共代码可以再抽一个抽象类来承载但接口这一层别省。2.3 继承 vs 实现什么时候该抽接口而不是抽父类这个问题我在代码评审里见过太多次争论。一个常见的场景两个类有相似的方法签名有人主张抽父类有人主张抽接口。我的判断逻辑是这样的——如果两个类共享的是行为实现方法体几乎一样且它们确实是同一族事物抽抽象类合理如果共享的只是方法签名契约相同但实现各异那必须抽接口。举个具体例子FileLogger和ConsoleLogger都有log(String msg)方法但一个写文件一个打控制台实现完全不同这时候抽Logger接口而不是抽一个带空方法体的AbstractLogger父类。后者会让子类被迫继承一个没用的父类还占掉了唯一的继承名额。类图上区分也很直观抽接口画虚线三角抽父类画实线三角。评审的时候看到实线三角我就会多问一句“这俩真的是 is-a 吗”看到虚线三角则相对放心因为接口实现的门槛低、耦合松。3. 依赖最弱但最容易被画错的那根虚线依赖是六种关系里耦合最弱的一种但恰恰是最容易画错、也最容易被忽视的。很多人画类图只要两个类有关系就画实线把依赖也画成关联结果图上一堆实线读图的人以为处处强耦合实际上大部分只是临时用一下。这一节把依赖讲透。3.1 依赖在代码里的四种典型形态依赖的语义是“一个类在某个时刻需要用到另一个类但不是长期持有”。类图上用虚线加开口箭头从使用者指向被使用者。Java 里依赖通常出现在四个位置方法参数public void process(Order order)方法执行时需要Order但类本身不持有它。局部变量方法体内Item item new Item()用完就丢。返回值public Report generate()返回一个对象调用方拿到就用。静态方法调用MathUtils.calc(x)直接调工具类。public class OrderService { // 依赖 PaymentGateway作为方法参数传入 public void checkout(Order order, PaymentGateway gateway) { double amount order.getAmount(); gateway.charge(amount); } // 依赖 ReportBuilder作为局部变量创建 public String export(Order order) { ReportBuilder builder new ReportBuilder(); return builder.build(order); } }注意上面代码里OrderService并没有把PaymentGateway或ReportBuilder存成字段它们只是“路过”。这就是依赖和关联的分水岭——有没有成为成员字段。3.2 依赖箭头方向谁指向谁不能凭感觉依赖箭头的方向是“使用者指向被使用者”也就是“谁需要谁箭头指向谁”。上面代码里OrderService需要PaymentGateway所以箭头从OrderService指向PaymentGateway。这个方向搞反了读图的人会以为PaymentGateway反过来依赖OrderService语义完全错乱。我见过一种常见错误有人觉得“被依赖的东西更重要所以箭头指向它表示强调”这个理解是错的。UML 箭头的语义是“导航性”和“依赖方向”不是“重要性”。画图的时候默念一句“我需要你我指向你”基本不会错。3.3 依赖过多是设计在报警依赖本身是正常的但如果一个类的类图上伸出七八条虚线指向不同方向这就是设计在报警了。依赖过多意味着这个类知道的太多、职责太杂稍微改一下被依赖的类它就可能受影响。我在实际项目里遇到过一个OrderController类图上连了十几条依赖线后来拆成三个类才把线降下来。一个实用的自查方法数一数一个类的方法参数里出现了多少个不同的业务类型。如果超过五个基本可以考虑把部分逻辑下沉到专门的协作类里。依赖不是越少越好但每一条依赖都应该是“这个类真的需要知道那个类”的合理理由而不是顺手就调了。4. 关联字段持有关系一对一还是一对多关联是比依赖强一档的关系语义是“一个类长期持有另一个类的引用”在代码里体现为成员字段。类图上用实线加普通箭头或双向箭头。关联是业务建模里出现频率最高的关系也是最需要把“多重性”标清楚的关系。4.1 关联与依赖的分界线就在“字段”二字还是拿代码说话。下面这个Customer类持有一个Address字段这就是关联不是依赖public class Customer { private Address address; // 关联长期持有 public Customer(Address address) { this.address address; } public Address getAddress() { return address; } }对比上一节的OrderService它的PaymentGateway只是方法参数用完就没了。区别一目了然字段是关联参数是依赖。类图上Customer到Address画实线箭头OrderService到PaymentGateway画虚线箭头。这里有个细节值得说关联字段可以是构造时注入的也可以是 setter 注入的但只要是字段就是关联。有些人觉得“构造注入的才算关联setter 注入的算依赖”这是误解。判断标准只有一条——是不是成员字段。4.2 多重性标注1、0..1、* 到底怎么标关联关系最容易被省略的信息是多重性multiplicity。一个客户有一个地址标1一个客户可能有零个或一个备用地址标0..1一个订单包含多个订单项标*等价于0..*。这些标注写在箭头两端读图的人立刻知道数量约束。标注含义Java 中的体现1恰好一个单个非空字段0..1零个或一个可空字段*或0..*零个或多个List、Set等集合1..*至少一个集合 校验public class Order { private ListOrderItem items; // 多重性 * }多重性标注的价值在于它把“业务约束”画进了图里。一个订单至少有一个商品标1..*读图的人就知道创建订单时必须校验非空。如果只画一根光秃秃的线这些约束就丢了后面实现的时候容易漏。4.3 双向关联的代价与单向化的取舍关联可以是单向的也可以是双向的。双向关联在代码里就是两个类互相持有对方的字段public class Student { private ListCourse courses; } public class Course { private ListStudent students; }这种写法在业务上很常见学生选课、课程有学生但维护起来有代价任何一方的增删都要同步更新另一方否则数据不一致。我的经验是能单向就单向确实需要双向导航的时候选一个“主控方”负责维护关系另一方只读或者通过主控方反查。类图上双向关联画一条两端都带箭头的实线或者两条单向线前者更简洁但要在图上注明哪边是主控。5. 聚合与组合整体与部分差的不只是一个菱形聚合和组合是六种关系里最容易被混为一谈的一对。两者都是“整体持有部分”代码里都体现为字段类图上都是实线加菱形区别只在菱形是空心还是实心。但这一空一实之间差的是生命周期的归属——部分能不能脱离整体独立存在整体销毁时部分跟不跟着销毁。这一节把这对关系彻底掰开。5.1 聚合部分可以独立于整体存在聚合的语义是“整体包含部分但部分可以独立存在”。典型例子是“班级和学生”——班级解散了学生还在可以转到别的班级。类图上用空心菱形画在整体端箭头指向部分。public class Classroom { private ListStudent students; // 聚合学生从外部传入 public Classroom(ListStudent students) { this.students students; // 注意直接引用外部传入的集合 } }关键特征部分对象是在整体外部创建好之后传进来的整体只是持有引用。学生对象的生命周期不由班级控制班级销毁了学生对象可能还被别的地方引用着。这就是空心的含义——关系比较“松”。5.2 组合部分的生命周期由整体完全掌控组合的语义是“整体拥有部分部分不能独立存在”。典型例子是“订单和订单项”——订单删了订单项就没有意义了跟着一起消失。类图上用实心菱形画在整体端。public class Order { private final ListOrderItem items new ArrayList(); // 组合内部创建 public void addItem(String productId, int qty) { items.add(new OrderItem(productId, qty)); // 部分在整体内部创建 } }关键特征部分对象在整体内部创建外部拿不到它的独立引用整体销毁时部分跟着销毁。订单项离开了订单就没有存在意义所以用组合。实心菱形表达的就是这种“强拥有”关系。5.3 空心与实心生命周期归属的判定清单判断该用聚合还是组合我一般用下面这张清单逐条过判定问题答“是”倾向说明部分对象是否在整体外部创建后传入聚合外部能独立管理部分部分对象是否在整体内部 new 出来组合整体完全掌控创建整体销毁时部分是否还有独立意义聚合部分能独立存活部分是否只能属于一个整体组合强归属不可共享外部是否需要单独访问部分对象聚合需要独立引用这张表不是绝对的实际建模时会有灰色地带。比如“部门与员工”员工可以被部门持有但员工离职后依然存在倾向聚合但如果业务上规定“员工记录随部门撤销一并归档删除”那就偏组合了。关系类型跟着业务语义走不是跟着代码写法走。同样是List字段语义不同画的菱形就不同。注意聚合和组合在 Java 代码层面的差别其实很小都是字段持有。真正的差别在对象创建权和生命周期管理上。画图的时候如果拿不准就问自己一句“这个部分对象我能不能在整体之外单独 new 出来用”能就是聚合不能就是组合。6. 六种关系横向对比与选型决策前面五节把六种关系逐个拆开了这一节做横向对比把容易混淆的几对放在一起对照再给一套实际画图时的决策流程。这部分是我觉得最有价值的地方——单独看每种关系都懂一到实际场景就选错往往是因为缺少横向对照的视角。6.1 三组高频混淆关系的对照拆解第一组继承 vs 实现。都是空心三角区别在实线虚线。判断标准是“是不是一种”用继承“能不能做”用实现。一个类只能继承一个但能实现多个所以接口优先。第二组依赖 vs 关联。都是“用到另一个类”区别在“是不是字段”。方法参数、局部变量、返回值、静态调用都是依赖成员字段才是关联。画图时先看代码里有没有那个字段。第三组聚合 vs 组合。都是“整体持有部分”区别在生命周期归属。部分能独立存在是聚合空心菱形部分随整体生死是组合实心菱形。这三组混淆覆盖了类图关系里百分之八十的错误。我把它们整理成一张决策表你的问题答案对应关系子类是不是父类的一种是继承这个类是不是要实现某个契约是实现这个类只是临时用一下另一个类是依赖这个类长期持有一个字段是关联持有的对象能从外部传进来、能独立存活是聚合持有的对象在内部创建、随整体销毁是组合6.2 从代码反推类图关系的实操流程拿到一段陌生代码怎么快速反推出类图关系我的流程是这样的先扫extends和implements把所有继承和实现关系画出来这部分最机械不会有歧义。再扫成员字段每个字段对应一条关联线然后逐个判断是普通关联、聚合还是组合——看字段是构造注入还是内部 new看有没有对外暴露独立引用。最后扫方法签名参数类型、返回类型、方法体内 new 出来的对象这些对应依赖线。补多重性集合字段标*可空字段标0..1必填单字段标1。这个流程走一遍一个中等规模模块的类图基本就出来了。我一般用纸笔先画草稿理清关系之后再上工具。工具方面文本化的 PlantUML 和 Mermaid 都行但注意 Mermaid 在部分渲染环境里对菱形支持有限PlantUML 的类图语法更完整写起来也直观startuml class Order { - orderId: String addItem(item: OrderItem): void } class OrderItem class Customer class Address Order 1 *-- 1..* OrderItem : 组合 Customer 1 o-- 0..1 Address : 聚合 Customer 1 -- 0..* Order : 关联 enduml上面这段里*--是组合o--是聚合--是普通关联|--是继承|..是实现..是依赖。记住这几个符号写文本类图基本够用了。6.3 关系选错之后的重构信号最后聊聊关系选错了会有什么症状这些症状就是重构的信号继承用错子类里出现大量throw new UnsupportedOperationException()的空实现说明子类根本不是父类的一种该改成组合或接口。依赖画成关联类里存了一堆只用一次的字段构造函数参数越来越多说明这些本该是方法参数改成依赖能降低耦合。组合画成聚合部分对象被外部随意传入传出状态经常不一致说明生命周期该由整体掌控改成组合。聚合画成组合部分对象想复用到别处却拿不到引用只能复制一份说明该放开成聚合。这些信号我在实际项目里都遇到过尤其是第一条和第三条改起来动静不小但改完之后类的职责清晰很多。类图关系的本质是用图形语言把设计意图固化下来图画对了代码结构往往也跟着对了。7. 画类图时那些文档里不会写的经验前面讲的都是“应该怎么画”这一节聊点实操层面的东西——工具选择、评审习惯、常见翻车点。这些内容教科书上不会有但真正画图的时候天天遇到。7.1 工具选型文本化优先别一上来就拖拽类图工具分两类拖拽式的图形工具和文本化的描述语言。我的建议是优先用文本化工具PlantUML 是首选Mermaid 作为备选。原因很实际文本类图能进版本库改一个关系就是改一行文本diff 看得清清楚楚拖拽式工具画出来的图是二进制或者私有格式改起来靠手拖团队协作时冲突没法合并。当然如果是给非技术方做汇报拖拽工具画出来的图确实更好看这时候可以先用文本工具把关系理清楚再导到图形工具里美化。但关系逻辑一定要先在文本层面定下来别一边拖一边想容易画着画着就乱了。7.2 类图评审时我必问的三个问题团队里评审类图我一般只问三个问题基本能覆盖大部分设计问题第一问“这条实线是关联还是聚合部分对象从哪来的”——逼着画图的人说清楚生命周期归属。第二问“这个继承子类能理直气壮说‘我是一种父类’吗”——筛掉为了复用而滥用的继承。第三问“这个类伸出去这么多依赖线它到底负责几件事”——发现职责过载的类。这三个问题问下来类图上大部分含糊的地方都会被逼出明确答案。评审的目的不是挑刺而是让画图的人把脑子里模糊的关系想清楚图画清楚了代码写起来自然顺。7.3 别把类图画成代码镜像最后一个经验也是我踩过最深的坑类图不是代码的逐行翻译。早期我画类图恨不得把每个字段每个方法都画上去结果图大得像一面墙没人看。后来才明白类图的价值在于突出关系结构而不是罗列成员。一个类画三五个关键成员就够了方法只画跟关系相关的字段只画体现关联的。具体做法画图前先问“这张图要回答什么问题”。如果是回答“模块之间怎么依赖”那就重点画依赖和关联成员细节省略如果是回答“继承体系怎么设计”那就重点画继承和实现字段可以全略。一张图只回答一个问题这个原则让我画的类图从“没人看”变成了“评审时被追着问细节”。类图这东西画多了会发现它其实是一种思维训练——逼着你在写代码之前把关系想清楚。六种关系看起来是六个符号背后是六种不同的耦合强度和生命周期约定。把这几组关系吃透再回头看自己写过的代码很多“当时觉得没问题、后来改起来要命”的地方根子都在关系选错了。我现在的习惯是动手写一个稍微复杂点的模块之前先在纸上把类图草稿画出来关系线画不顺的地方代码结构八成也有问题。这个习惯帮我省下的返工时间远比画图花的时间多。