Oop 不必要地通过中间人传递对象引用

我经常发现自己需要引用一个相隔几个对象的对象，或者看起来是这样。我看到的选项是通过中间人传递引用，或者只是静态地提供一些东西。我理解全局范围的危险，但是通过一个与之无关的对象传递引用感觉很可笑。我想我可以随便转转。我怀疑在某个地方会有一条界线

有人知道这条线在哪里吗

---

还是处理在依赖对象之间分配引用问题的好方法？

这是一种可能需要改进的抽象。你似乎违反了

的使用规则（适度且有品位，而不是教条主义）。如果您正在编写

a.b.c.d.e

，那么一定是出了问题--您已经将

a

的实现永远钉在了一个

b

上，它有一个

c

它。。。EEP！-）一个或最多两个点是您应该使用的最大值。但另一种选择是不要把东西塞进全局（并确保线程不安全、有缺陷、难以维护的代码！），而是让每个对象“表面化”它设计用来维护的那些特性，作为其与客户机接口的一部分，而不只是让可怜的客户机通过嵌套的引用链

我有三种模式：

将必要的引用传递给对象的构造函数——然后可以将引用存储为对象的数据成员，而无需再次传递；这意味着对象的工厂具有必要的引用。例如，在创建DOM时，在构造DOM节点时将元素名称传递给DOM节点

让事物记住它们的父对象，并通过它们的父对象获取对属性的引用；这意味着父代或祖先具有必要的属性。例如，当我创建一个DOM时，有各种东西被存储为顶级DomDocument祖先的属性，它的子节点可以通过每个节点对其父节点的引用来访问这些属性

将所有作为引用传递的不同内容放在一个类中，然后只传递一个类实例作为唯一传递的内容。例如，呈现DOM需要许多属性（例如GDI图形句柄、视口坐标、回调事件等）。。。我将所有这些内容放在一个“Context”实例中，该实例作为惟一的参数传递给要呈现的DOM节点的方法，每个方法都可以从该Context参数中获得它需要的任何属性

---

在某些情况下，全球变暖并不太糟糕

考虑一下，您可能正在针对操作系统的API进行编程。这里面充满了全局变量，您可能可以访问文件或注册表，写入控制台。向上看窗把手。你可以做大量的事情来访问整个计算机甚至整个互联网的全局状态。。。您不必向类传递一个引用就可以访问它。如果你访问操作系统的API，所有这些都是全球性的

<> P>这样，当你考虑经常存在的全局事物的数量时，你自己的程序中的一个全局可能并不像许多人尝试、制造和尖叫的那么糟糕。 然而，如果你想拥有非常好的OO代码，并且这些代码都是可以进行单元测试的，我想你应该围绕着对全局变量的任何访问编写包装类，不管这些全局变量是来自操作系统，还是自己声明来封装它们。这意味着使用此全局状态的类可以获取包装器的引用，并且可以用赝品替换它们

---

嗯，不管怎样。我不太确定我想在这里给出什么建议，除了说，结构化代码是一种平衡！而且，如何解决您的特定问题取决于您的偏好、将使用代码的人的偏好、您在从学术到实用的范围内的感受、代码库有多大，系统的安全性有多重要，离完成期限还有多远。

我相信你的问题揭示了你的课程。也许责任可以改进？也许移动一些代码可以解决问题

---

告诉我，不要问

我就是这样解释的。人们自然倾向于调用类来获取一些数据。走得太远，要求太多，通常会导致沉重的“getter序列”。但还有另一种方法。我必须承认，这并不容易找到，但在特定的代码和程序员的习惯中会逐渐改进

类A想要执行计算，并询问B的数据。有时，A告诉B做这项工作是合适的，可能会传递一些参数。这可以用B上的“isValid（）”方法替换A用来检查名称有效性的B的“getName（）”。 “询问”已被“告诉”（调用执行计算的方法）取代

对我来说，当我发现太多的getter电话时，我会问自己这个问题。渐渐地，这些方法在正确的对象中找到了它们的位置，一切都变得更简单了，我有更少的getter和对它们的调用。我有更少的代码，它提供了更多的语义，更好地符合功能需求

---

移动数据

在其他情况下，我会移动一些数据。例如，如果一个字段向上移动两个对象，“getter链”的长度将减少两个

我相信最初没有人能找到正确的模型。 我先想一想（用手写的图表很快而且很有帮助），然后编写代码，然后面对真实的东西再想想。。。然后我对其余的代码进行编码，我在代码中感觉到的任何气味，我会再次思考

---

拆分和合并对象

如果a上的方法需要C的数据，则B为