• [答疑]《实现领域驱动设计》的译者其实没错?(一)


    DDD领域驱动设计批评文集>>

    《软件方法》强化自测题集>>

    《软件方法》各章合集>>

    Jasmine 2022-8-7 19:54

    有一个地方想和您商榷,这张图上说对象树是译者的臆想,我觉得译者译成对象树也对,因为聚合根和其他对象是一对多关系,您觉得呢?

    ******

    以下不属于问题内容,属于回答者补充的背景:

    此图摘自我写的《DDD话语批评之一:评张逸的“状态和事件本质相同”》,图中内容是《实现领域驱动设计》(Vaughn Vernon 著,滕云 译,张逸 审,电子工业出版社)中某段内容的英文原文和中文译文对照,加了一些批注。

    关于此图的更多评论,还可以参见我的另一篇文章《猴子掰玉米?比较不同版《领域驱动设计》说“不变式”和“聚合”》

    ******

    UMLChina潘加宇

    (1)

    “对象树”在某些情况下是对的。

    如果组合(聚合)关联的整体一端的多重性上限为1,也就是说,部分对象在同一时间最多只属于一个整体对象,那么这个整体-部分的对象链接结构确实是一棵有向树。

    例如,图1左侧的类图就可能得到右侧形状的对象图(树)。

    图1

    如果一个部分对象可以属于多个整体对象(实际上这时整体-部分的含义已经模糊),那就是一张有向无环图,如图2。

    图2

    这意味着组合(聚合)是非对称的:如果对象B是对象A的部分,那么对象A不能直接或间接成为对象B的部分。

    “间接”背后的意思是:组合(聚合)是传递的,如果对象B是对象A的部分,对象C是对象B的部分,那么,对象C是对象A的部分。

    像图3是不允许的。C是B的部分,B是A的部分,也就意味着C间接是A的部分,那就不允许A同时也是C的部分。

    图3

    (2)

    “对象树”有道理是不是意味着“译者译成对象树也对”?这个倒要好好说一说。

    原文用词是graph of … objects(对象图),是不是译者像您(提问者)这样,想到了这一点,站得高看得远,然后毅然出手纠正作者,把译文改为“对象树”呢?

    我们把这段译文一句一句仔细看看就知道了,看看译者(以及审校者)的水平是不是有三四层楼那么高。

    还可以参见我之前写的文章:

    《实现领域驱动设计》的翻译错误>>

    (3)

    原文:

    Is an Aggregate just a way to cluster a graph of closely related objects under a common parent?

    中译本译文:

    聚合只是将一些共享父类、密切关联的对象聚集成一个对象树吗?

    大问题:

    “共享父类的对象”的说法在概念上是错误的。

    我的剖析:

    原文只是说under a common parent,“共享”属于译者自由发挥。

    译者可能搞混了类和对象,搞混了集合和个体,看到原文的parent,误以为是“父类”(其实是整体对象),从而臆想出“共享父类”、“一个(应为一棵)对象树”的译文。

    说“共享父类的类”或“类的对象”或“共享父类的类的对象”都可以,但不应说“共享父类的对象”。

    “共享父类的类”的类图(不考虑多继承)如图4左侧的树,但是这棵树是“类(集合)”的树,不是“对象(个体)”的树。对象关系是像图4右侧这样的。

    图4

    以人举例,“共享父类的类的对象”是由若干“中国男人”对象、“美国女人”对象……组成的集合,它们的类的父类都是“人”。

    读者可以自行体会"人有男有女"、“人有手有脚”、“人有车有房”、“人有高富帅有屌丝”的区别。

    当然,作者此处用parent一词欠考虑,但还是尽量尊重原文,parent可译为“父对象”。

    中问题:

    related不是“关联”。

    我的剖析:

    “关联”一般指association,association一词在面向对象中有特定含义,组合(聚合)就是一种特殊的关联。

    在问题所给图片中可以看到,在本句之后就有association出现,“can the associations be navigated……”,作者在这里用词还是很准确的。

    related可以译成“相关”。

    这个看起来像是个小问题,无非是译者用词比较随意,但并非如此。

    Aggregate的各个部件之间只是相关(related),并不需要存在关联(association)。

    以人举例,类图如图5:

    图5

    手、眼、心、肝这些部件和整体对象存在关联(组合关联),但它们之间并不需要存在关联,像图6这样:

    图6

    注意:我的用词是“不需要存在”。如果你要是执意要像图6这样做,也不是不可以,只不过是一个不良结构。

    可能有的开发人员会想,图6有道理呀,这些部件之间有“兄弟”或“同事”关联呀!其实这些“兄弟”或“同事”是从整体-部分关联推算出来的冗余概念,系统不需要维护。

    部件之间说“相关(related)”可以。

    怎么个相关?静态上,它们都是人的部件,动态上,它们在某个场景中由整体对象协调来完成任务,如图7:

    图7

    *注意:可能某些部件并不需要参与某个场景,也就是说,图5中某些类的对象不一定出现在图7中(当然,可能会出现在其他场景中)。这个知识点,评点后面几句译文时还会再提到。

    建议译文:

    聚合只是把在共同父对象之下紧密相关的对象图聚集在一起的一种方式吗?

    (待续)

  • 相关阅读:
    批量虚化边框并一键褪色的简单教程
    搭建数字孪生车间需要哪些关键技术?
    C#进阶-ASP.NET常用控件总结
    Java 类和对象 详解+通俗易懂
    基于Python的接口自动化-JSON模块的操作
    Operator 开发实践 五 (多版本API)
    渲染富文本编辑器并设置富文本编辑器的高度
    Python数学基础二、利用正弦sin求曲边图形的面积
    软件架构设计的底层核心
    react高阶组件——HOC
  • 原文地址:https://blog.csdn.net/rolt/article/details/126357940