我经常发现自己处于对象之间需要相互通信的情况。例如，按钮可能需要与各种文本框进行通信。简单地用一个指向所有容器的容器的指针来构造每个小部件是否合适？给它一个指向资源容器映射的指针会更好吗，对象可以通过字符串或其他东西找到另一个对象？这方面对我来说一直很模糊。如果我只使用指向每个其他对象的容器的指针构造对象，我可以轻松实现我想要做的所有事情，但这似乎是错误的。在小部件的情况下，如果小部件对外部世界一无所知并且其动作侦听器是使用资源访问构建的，那么它实际上是否更合适？
由于
我知道这是一个坏主意，但在这些情况下有哪些解决方案，例如：良好的设计模式？
答案 0 :(得分：3)
任何对象都应该尽可能少地了解自身之外的事物。您所描述的内容听起来很像ani-pattern，通常被称为'God object'
如果使用消息/事件，则会更好地解耦。
答案 1 :(得分：1)
带有指向每个其他对象的容器的指针的对象，但这似乎是错误的。
为什么你认为这是错的？
通常，您不仅需要发送消息，还需要执行导航/枚举等操作。
例如，HTML DOM树由节点组成，其中每个节点包含对其父节点的[弱]引用。没有像nextSibling（）这样的参考操作是不可能的。
因此，答案取决于您希望在那里实施的其他一系列操作。
答案 2 :(得分：0)
答案取决于对象可能存活的时间以及指针可能会持续多长时间。任何可能发生变化的东西都需要通过目录服务。如果目标的生命周期足够短，您甚至可能需要让目录服务暂停目标。
答案 3 :(得分：0)
答案 4 :(得分：0)
为什么对话框中的按钮（？）想要知道对话框中有多少其他对象？
按下按钮时，它会向其所有者发送消息。然后，所有者必须协调它拥有的小部件之间的操作。当对话框获得另一个列表框时，你不想为你改变代码OK-button，是吗？
答案 5 :(得分：0)
您可以使用依赖注入来传递您需要的指针。这样就可以使依赖项显式化。 http://en.wikipedia.org/wiki/Dependency_injection
这种方法为您提供了很多优势 - 当您没有全局状态，神对象等时，单元测试会更容易。此外，当新人加入团队时，他可以看到一个类的依赖关系 - 你在构造函数中使它显式化，所以没有魔法，比如“你必须首先创建这个单例来使用该对象，否则它将崩溃”。这种方法减少了耦合，从而使重用更容易。
IMO不可能使每个班级独立于所有其他班级（当你对外部世界一无所知时，你会问它是否更好）。虽然这消除了耦合使代码重用更容易，但也很难做到并导致更多的编码。
另一方面，追求一些意识形态“仅仅因为”而不理解为什么是一个坏主意。也许在你的情况下，OOP的优点不值得编写额外的代码。如果你能看到你用“上帝对象”更快地完成你的应用程序，那么我会说“去吧”。
IMO并不像“永远不会创造单身和神物”那么容易。您必须确定将来所有参考文件上花费的额外时间是否明确还款。
我个人总是选择适合我写的程序。我有意识地打破一些OOP规则并不罕见。请记住，还有其他指导方针 - 我喜欢KISS。