单向关联和依赖的区别答案

【问题标题】：difference between unidirectional association and dependency单向关联和依赖的区别
【发布时间】：2013-05-02 10:59:56
【问题描述】：

根据维基百科

依赖性是一种关系，它表明一个元素或一组元素需要其他模型元素来进行规范或实现。[1]该元素依赖于称为供应商的独立元素。

那么它与单向关联不一样吗？当一个类中的操作使用另一个类的对象作为其参数时，我们是否使用依赖关系？

单向关联和依赖有何不同。任何例子都会很有帮助

【问题讨论】：

标签： oop dependencies uml

【解决方案1】：

依赖：

表示 client 元素（任何类型，包括类，包、用例等）了解另一个 supplier 元素，供应商的变化会影响客户。

所以“依赖”是很广泛的关系。假设如果一个类对象（客户端）有另一个类对象（供应商）作为成员，如果一个类对象发送消息到另一个类对象，如果一个类对象将另一个类对象作为其方法的参数，即使一个类（客户端）是另一个类（供应商）的子类，也会存在依赖关系，因为供应商的更改会影响客户。

从技术上讲，所有这些关系都可以通过“依赖”行显示。但是上面的一些关系已经有了特殊的表示法：比如超类-子类关系我们有泛化关系。没有必要同时显示“依赖”线，因为如果它们有泛化关系，它们就有依赖关系。我们对具有另一个类对象作为成员[属性]的类对象（客户端）具有“关联”关系。所以在这种情况下也不需要显示额外的依赖行。

实际上，“依赖”是类图定义错误的关系。但它对于显示 UML 没有特殊符号的依赖关系很有用，例如：

如果您的某个类（客户端）方法中有另一个类对象（供应商）作为参数
如果您依赖于全局变量
当您在其他类上调用静态方法时。
局部变量（你认为你有重要的依赖）

public class RepositoryManager
{
     public UpdatePriceFor(ProductDescription description)
     {
          Time date = Clock::GetTime();
          Money oldPrice =description.GetPrice();
          ...
     }

    private  IList<Item> itemsList = new List<Item>();

}

所以所有“关联”也都显示“依赖”。但是“依赖”是广泛-一般-弱关系。通常如果有特殊比依赖更具体的关系关系而不是使用它。 最后使用你所有的关系 “经济上”。基于建模器模型阅读器仅显示重要的观点。

[ 来源：改编自 Craig Larman 的 Applying UML and Patterns book ]

查看 Fowlers bliki 了解更多信息DependencyAndAssociation

【讨论】：

好吧，根据@vainolo，如果一个类调用另一个类的方法，那么它应该被建模为单向关联。你说如果调用 getTime() 它是一个依赖项？
如果我们调用它的methods[supplier]的对象是我们类的(client)属性，那么使用关联是合适的。但是如果不是client的属性，即它是局部变量或静态方法调用，那么最好将其显示为依赖项。在我的示例中 getTime() 是静态调用。即使它不是静态的，所以我们创建本地 Clock 变量并调用它的 getTime() 方法仍然最好将其显示为依赖项。但是假设 Clock 对象是 RepositoryManager 的成员属性而不是通过关联显示它更好。
Money 类也是 UpdatePriceFor 方法中的局部变量。因为它不是 RepositoryManager 的属性，所以最好用依赖来展示它。但即使我选择不展示它，因为我不想让我的类图“脏”有很多依赖

【解决方案2】：

关联意味着两个关联的实体在语义上是联系在一起的。依赖关系只声明存在......嗯，某种依赖关系。所有关联都是依赖关系，而依赖关系实际上并不意味着关联。例如，如果类“A”有一个方法接受“B”并将其作为参数传递给另一个类中的函数，则它依赖于类“B”。但是如果'A'调用了'B'类的某个方法，它应该被建模为关联。

免责声明 我已经阅读了 UML 规范，也多次问过自己这个问题。我得出了上面的定义，但我仍然不确定它是否 100% 正确。

【讨论】：