使用源代码区分聚合和组合关系

时间:2011-07-21 12:25:34

标签: uml class-diagram

是否可以通过阅读源代码来区分组合和聚合关系?

我试图找到一些模式,我在下面列出了它们。

我以this site为例解释我认为的模式

组合物

enter image description here

 public class Engine
{
    . . . 
}

public class Car
{
   Engine e = new Engine();
    .......
}

聚集

enter image description here

public class Address
{
. . .
}

public class Person
{
   private Address address;
   public Person(Address address)
   {
     this.address = address;
   }
   . . .
}

我发现这些模式可以区分

成分(属于其中一部分)

  1. 定义为一个类的字段。

    • 示例:[Engine e] Engine被定义为Car类
    • 的字段e
  2. 在班级中实例化并分配。

    • 示例:[Engine e = new Engine();]引擎在内部实例化 类
  3. 聚合(有一个)

    1. 定义为类的字段

      • 示例:[私有地址;]地址定义为字段 类Person的地址
    2. 在课堂上实施

      • 示例:[地址address = new Address();]地址已实例化 外人。
    3. 通过将实例作为参数发送给构造函数,在构造函数中赋值。

      • 示例:[Person person = new Person(address);]实例 地址作为参数通过构造函数传递并分配 在Person类的构造函数中。
    4. 我是否可以考虑这些以区分聚合和组合关系?

      是否存在更多用于区别对待的限制因素?

3 个答案:

答案 0 :(得分:1)

不是真的,因为没有一种独特的方式来实现每种关联(事实上,问题是我们有三种关联,“正常关联”,“聚合”和“组合”)。

如果语言有指针,那么你可以尝试猜测如果Engine在Car中被定义为指针,则编写该段代码的程序员建议汽车和引擎之间的关系(聚合或关联)更加柔和,因为删除了Car并不意味着丢失Engine对象。

答案 1 :(得分:1)

你可以查看这个类似的问题(不是我的),标记为“首选”/“acepted”的答案是我的; - )

Aggregation and Composition representation in class definition?

这取决于构建该代码的人是否确实应用了这些设计模式。

答案 2 :(得分:0)

<强>协会

关联是一种关系,其中所有对象都有自己的生命周期,并且没有所有者。让我们举一个教师和学生的例子。多个学生可以与单个教师联系,单个学生可以与多个教师联系,但对象之间没有所有权,两者都有自己的生命周期。两者都可以独立创建和删除。

<强>聚合

聚合是Association的一种特殊形式,其中所有对象都有自己的生命周期,但是所有权和子对象不能属于另一个父对象。让我们举一个部门和老师的例子。单个教师不能属于多个部门,但如果我们删除部门教师对象就不会破坏。我们可以考虑“有一种”关系。

<强>组合物

组合再次是聚合形式的特殊形式,我们可以将其称为“死亡”关系。它是一种强大的聚合类型。子对象不具有其生命周期,如果父对象删除所有子对象也将被删除。让我们再来看一下House和房间之间的关系。房子可以包含多个房间没有独立生活的房间和任何房间不能属于两个不同的房子,如果我们删除房子的房间会自动删除。

所以,我不认为汽车和引擎之间的关系是组合,因为引擎可以不存在汽车,我认为汽车和引擎之间的关系是聚合。

长话短说;是的,通过阅读代码,您可以根据定义确定关系的类型(组合和聚合;但我不确定关联),我认为您的区分模式是正确的。