如果在方法中启动或引用对象，则类图中的关系类型是什么？

Question

我正在对一个系统进行逆向工程并创建一个类图。

代码与此示例类似：

class B
{
}

class C
{
}    

class A
{
    C GetC()
    {
       return new C();
    }

    void Foo()
    {
       B b = new B;
       C c = GetC(); // this function returns a reference to an object of type C
    }
}

我想知道我是否有这个代码A和B，A和C之间的关系是什么？

Answer 1

假设它是UML类图，那么你有一个依赖。来自Wikipedia（重点是我的）：

  

Dependency是一种较弱的键形式，表示一个类依赖于另一个类，因为它在某个时间点使用它。 如果独立类是依赖类的方法的参数变量或局部变量，则一个类依赖于另一个类。这与关联不同，其中依赖类的属性是独立类的实例。有时两个类之间的关系非常弱。它们根本没有使用成员变量实现。相反，它们可能被实现为成员函数参数。

例如：

在您的案例中，班级A 使用班级B和班级C。它是一个依赖项，它不是composition，因为突出显示的文本：b和c（至少在该示例中）是局部变量，然后A与它们之间的关联仅仅是它们用法（甚至不是弱aggregation）。

好吧，说实话 - 我希望UML纯粹主义者不会责怪我太多 - 我会说使用而不是组合因为（从代码虚构的例子中猜测） b是用于完成Foo()任务的工具。如果使用它（即使是局部变量）（从外部角度来看）A 容器 B那么我会说组合。例如，在这种情况下：

class RocketLauncher {
    public void Launch(World world, Location target) {
        AutonomousObject rocket = world.Rocket.Factory.Build(_structure);
        rocket.MoveTo(world, target);
    }

    private static LauncherStructure _structure;
}

即使严格来说{/ 1>} Rocket使用，我也倾向于将（RocketLauncher和LauncherStructure）定义为组合物。从外部的角度来看，Rocket由一个结构和一个火箭组成（由其组成）（即使当前实现将创建委托给最后一刻）。 Point（IMO）是您想要用此图表示的内容。如果您正在描述实现，那么观点并不重要：依赖是依赖，组合是组合。

如果您正在描述更高级别的体系结构，那么您可以将实现细节保留在图表之外并尝试描述类接口（当然，当实现与抽象体系结构大不相同时，可能会出现错误的气味 - 在实施或体系结构中 - 以及原因 - 如果有的话 - 必须记录）。

Answer 2

假设 GetC（）仅在 Foo（）中使用，则A与B和C的关系完全相同。< / p>

这是因为你可以重构代码看起来像这样：

void Foo()
{
   B b = new B;
   C c = new C;
}

这种关系是一种弱关系，因为它完全写在你的例子中。我会将其归类为依赖关系。

如果您将它们作为类变量，请执行以下操作：

B b;
C c;
void Foo()
{
   b = new B;
   c = new C;
}

您可能会关注聚合。如果要在构造函数中调用Foo（），那么你会看到组合（即 b 和 c 生存并死于对象）