确定适航性时要考虑的范围？答案

【问题标题】：Scope to consider when determining navigability?确定适航性时要考虑的范围？
【发布时间】：2018-09-16 16:08:03
【问题描述】：

在决定 ClassA 是否可以“导航到”ClassB 时，您是只考虑 ClassA 的字段/属性，还是还考虑 ClassA 的任何方法是否真正“导航到”ClassB 的任何对象？或者您是否考虑过 ClassA 的某些方法是否只是临时持有对 ClassB 任何对象的引用？

换句话说：假设我有一个 ClassA，它没有任何 ClassB 类型的字段。但是，我有一个方法 ClassA.method1(ClassB b)。当该方法被调用时，它通过调用 b.method2() 从 b 中提取信息，执行相应的操作，然后超出范围，但对 b 的引用不会永久存储在 ClassA 中。我是否表明 ClassA 可以导航到 ClassB？

更简单地说，假设 ClassA.method1(ClassB b) 只是将 b 传递给其他对象，而从不调用 b 上的任何方法。我是否指出 ClassA 可以导航到 ClassB 仅仅是因为它暂时持有对 ClassB 的引用？

或者，当且仅当 ClassA 具有 ClassB 类型的字段时，我是否指示 ClassA 可以导航到 ClassB？

【问题讨论】：

标签： uml class-diagram

【解决方案1】：

过去，可导航性意味着特定类拥有一个属性，该类可以通过该属性访问该属性的类型。句号。它与操作或实现方法无关。

现在可导航性意义不大，一个明确的“球”符号告诉你一个类，而不是一个关联，拥有一个属性。更改的原因是当协会拥有财产时，没有什么可以阻止类导航。（例如，考虑在表示关联的关系表中查询 RDBMS。）我根本不喜欢球符号，但它就是这样。

【讨论】：

没有人喜欢那个球。这只是一个“呃，那是什么？”对任何人（除了一些书呆子）。不幸的是，它现在是标准。

【解决方案2】：

可导航性是您并不真正需要的东西。它只是意味着“会有一些属性访问另一个类，但在当前的设计阶段我不知道如何调用它”。然而，这些隐含的属性大多是显而易见的。根据我的经验，只有极少数情况下您实际上应该使用导航来清除某些方面。在大多数情况下，我只使用一个普通的无向关联。在稍后的设计阶段，我添加了一个角色名称并使用点表示法使其成为一个拥有的属性。

对于操作使用另一个类作为参数或结果并且您没有显式属性的情况，您只需使用依赖关系。

【讨论】：

这个答案与我的问题无关。我没有就人们是否选择使用导航指标征求意见。
Thomas 的回答对我来说听起来不错。简而言之，可导航性的含义将取决于您的项目类型和模型使用（文档、代码生成、BD 生成等）。可以肯定的是，可导航性与 UML 关联有关，因此操作和类之间不相关。如果方法使用另一个类作为参数，则在元模型级别它们之间已经存在“关系”。如果一个方法在其代码中使用另一个类并且你想表达它，我会在操作或它的类所有者和第二个类之间使用依赖关系。
@RedBeard：听起来好像您在说我的示例实际上没有实际意义，因为在这种情况下插入关联连接器将是多余的。与其用额外的关联连接器使图表变得混乱，不如仅仅依靠为操作列出的参数所暗示的关联。因此，仅当类受到影响时才需要插入所述关联线，而列出的参数并不明显。谢谢你。这对我来说很清楚。让我知道我是否正确，我会写一个完整的答案。