UML继承关系箭头为何从子类指向父类而非反向？

这个问题确实戳中了很多UML新手的直觉困惑——毕竟从“B继承了A的所有方法”这个描述来看，很容易觉得箭头应该从A指向B，但UML这么设计其实是经过深思熟虑的，核心原因有这几个：

• 依赖关系的逻辑一致性
  UML里的箭头方向本质上代表的是依赖或信息流的方向。当B继承A时，B的定义完全依赖于A的结构——如果A修改了某个方法的签名，B的行为可能直接受影响；但反过来，A根本不需要知道B的存在，完全可以独立修改。箭头指向被依赖的一方（也就是父类A），这和UML里其他依赖关系（比如关联、接口实现）的箭头逻辑保持一致，整个符号体系更统一，不会出现规则矛盾。

• 可视化的层级清晰度
  当你绘制包含多个类的继承树时，子类箭头向上指向父类的设计，会让整个结构呈现出“从具体到抽象”的向上汇聚感。比如多个子类都指向同一个父类，你一眼就能识别出哪些类共享同一个基类，层级关系一目了然。如果反过来让父类箭头向下指向子类，当子类数量较多时，父类会冒出一堆杂乱的向下箭头，反而不利于快速理解整体结构。

• 行业规范的历史传承
  UML的设计整合了早期几种主流的面向对象建模方法（比如Booch方法、OMT），这些早期规范就已经采用了子类指向父类的箭头方向。为了保持行业兼容性和开发者的使用习惯，UML延续了这个设计，避免了新旧规范切换带来的认知混乱。

简单总结一下：UML的继承箭头不是看“谁把东西传给谁”，而是看“谁依赖谁”——子类依赖父类的定义，所以箭头指向父类。

内容的提问来源于stack exchange，提问作者user194878