我想知道Driver License
和Room
聚合或合成之间的关系?对我来说很明显,Building
和Chair
关系是一个组合,Room
和Driver License
是一个聚合。但Human
可以在没有Human
的情况下存在,但如果没有$('body').on('click', '[data-setdata]', function(e) {
// do something
});
,它就无法存在。我卡住了。
答案 0 :(得分:1)
我认为,为了回答这个问题的疑问,我们应该确切地定义以下术语:
如果完全定义了上述术语,则使用合成或聚合没有任何疑问。
我的想法,如果我想问这个问题,请在我对术语的具体定义中说明:
因此,Human
和Driver License
之间的关系不能 真实世界背景中的合成。因为,通过摧毁Human
(消失,失去生命......),我们不会立即销毁Driver License
。它存在。
例如(在某些国家/地区),没有任何在线和最新的失效机制可以立即使Driver License
无效,因此它可以在没有{{{}的情况下存在1}}直到我们使它无效。所以在这段时间内(从消失Driver
到使Driver
失效)它存在,实例的有用性与它的存在无关。再次注意:它是我对Context和Existence的定义。
编辑(根据@Thomas Kilian的评论):
对于编程及其技术(如ORM)的上下文中的另一个示例,我们应该在删除Driver License
的实例后立即删除(使Driver License
Driver
(我们可以在这个上下文中完成)。所以关系应该是一个组合。
最后:我想在建模中指出 术语定义(Context和Existing及其他相关术语)的重要性。如果我们没有准确定义它们,那么问题就会出现很多解决方案(基于他们头脑中隐藏的定义)。
希望能提供帮助。
答案 1 :(得分:1)
由于驾驶执照不是人/人的一部分,而只是与她/他相关,因此它们之间既没有构成也没有聚合,而只是一个普通的协会。
Gholamali-Irani的回答混淆了这样一个事实:驾驶执照必须与一个人相关联(也就是说,协会结尾只有一个乘数),许多成分的(偶然)特征具有不可分割的部分,并错误地断定协会必须是一个作文。
在许多情况下,我们可能想知道一个关联是否是一个组合,将它建模为一个简单的关联更安全。
将关联建模(例如Human
- has - DriverLicense
)作为组合的唯一理由是当组件类型的实例(此处为驱动程序许可证)是“弱实体”时有自己的身份。但是驱动程序许可证确实有自己的ID,因此不需要也没有任何收获来将它们建模为其持有者的组件。
答案 2 :(得分:0)
聚合表示子项可以独立于父项存在的关系。示例:Class(父级)和Student(子级)。删除班级,学生仍然存在。
汇总示例:
重要的是要注意聚合链接不会以任何方式表明A类拥有B类,也没有说明两者之间存在父子关系(当父项删除其所有子项时都被删除)。实际上,恰恰相反!聚合链接通常用于强调A类实例不是B类实例的独占容器,因为事实上同一个B类实例具有另一个容器。
作文示例:
我们应该更具体,并且在除了A类和B类之间的部分关系之外的情况下使用组合链接 - 两者之间存在强烈的生命周期依赖关系,这意味着当删除A类时B类因此也会删除
组合意味着孩子不能独立于父母而存在的关系。示例:住宅(父母)和房间(儿童)。房间不是独立于房屋。
这里有一些额外的信息来详细说明Composition
的概念正如UML用户指南中的 Grady Booch 所述,Addison Wesley
然而,简单聚合的变体 - 组合 - 确实增加了一些重要的语义。组合是一种聚合形式,具有强大的所有权和一致的生命周期作为整体的一部分。 具有非固定多重性的零件可以在复合材料本身之后创建,但是一旦创建它们就会生存并随之死亡。 这些零件也可以在死亡之前被明确删除。复合物。
此外,在复合聚合中,整体负责其部件的配置,这意味着复合材料必须管理其部件的创建和销毁。例如,在窗口系统中创建框架时,必须将其附加到封闭窗口。 同样,当你破坏Window时,Window对象必须依次销毁它的Frame部分。
(来源:UML用户指南 - 作者:Grady Booch,James Rumbaugh,Ivar Jacobson,Addison Wesley)
总结 - (Read detailed Article)
总结一下,关联是一个非常通用的术语,用于表示在课堂上何时使用另一个类提供的功能。我们说如果一个父类对象拥有另一个子类对象,那么它就是一个组合,如果没有父类对象,那么子类对象就不能有意义地存在。如果它可以,那么它被称为聚合。