在OOP中，如果对象彼此发送消息，则为'；难道不容易出现无限循环吗？

在一篇关于面向对象编程的苹果论文中，它描述了对象之间发送消息的过程。因此，

设备

可以向

阀门

发送一条消息，表示请求水，

阀门

对象随后可以向

设备

发送一条消息，表示“给水”

（发送消息实际上是调用另一个对象的方法）

所以我想知道，这会不会以某种连程序员都没有预料到的方式导致微妙的无限循环？例如，一个是，如果我们编程两个对象，每个对象都通过重力相互拉动，因此一个对象向另一个对象发送“拉力”，另一个对象的方法被调用，然后依次向第一个对象发送消息，它们将进入无限循环。因此，如果计算机程序只有一个进程或一个线程，它将进入一个无限循环，并且永远不会运行该程序中的任何其他程序（即使两个对象最终碰撞在一起，它们仍会继续相互拉动）。这种编程范式在现实中是如何防止这种情况发生的

更新：这是苹果的报纸：

更新：对于那些看到这个明显的例子就说“你错了！程序应该是有限的，诸如此类”的人，我的目标是，如果有成百上千个对象，它们相互发送消息，当收到消息时，它们可能反过来向其他对象发送其他消息。那么，你怎么能确定不存在无限循环，程序不能再继续下去呢

---

另一方面，对于那些说“程序必须是有限的”的人来说，那么，一个简单的GUI程序呢？它有一个事件循环，它是一个无限循环，一直运行到用户明确要求程序停止为止。那么一个不断寻找素数的程序呢？它可以继续查找（比如在Ruby中使用BigNum，这样整数就可以有任意数量的数字），因此程序只是为了继续运行而编写的，然后将下一个较大的素数写入硬盘（或者，当它找到更大的素数时，每一百万次写入硬盘一次——因此它找到一百万个素数，并将第一百万次写入硬盘，然后继续查找下一百万个素数，并将第二百万次写入硬盘（只写入一个数，而不是一百万个）.嗯，对于一台有12GB或RAM和2TB硬盘的计算机，当硬盘已满或12GB的RAM无法容纳所有变量时（可能需要数十亿年的时间，一个整数不能容纳1GB的RAM），您可以说程序可能需要20年才能超过计算机的容量，但就程序而言，它只是继续运行，除非内存管理器无法分配另一个BigNum，或者硬盘驱动器已满，否则会引发异常并强制停止程序，但程序会被写入无限期运行。因此，并非所有程序都必须被写入有限的程序。

为什么要

Appliance

反复请求供水？
为什么

阀门

要轰炸

设备

说有水供应

从理论上讲，它可能会创建无限循环，但在实践中，它归结为对象的正确建模

Appliance

应该只发送一次

ICanHasWater

消息，等待响应，收到水或者收到无法提供水的答复，或者将来当

Appliance

可能想再次尝试请求水时会收到

---

这就是为什么我转而讨论2个物体和重力的例子

只有在计算时触发此计算，才会发生对象之间重力效应的无限循环计算

---

我认为常用的方法是引入

时间

概念，计算特定

时间段

的引力，然后进入下一个时间段进行下一轮计算。这样，您的

世界

将控制

时间段

之间的线程，并且您的应用程序可能会做一些更有用的事情han无休止地计算重力效应。

如果没有OOP，可能会使用命令式编程语言或函数式编程无意中创建无限循环。因此，我看不出OOP在这种情况下有什么特殊之处

如果您将对象视为相互发送消息的参与者，那么进入无限循环并不一定是错误的。GUI工具包就是这样工作的。这取决于所使用的编程语言，通过调用

toolKit.mainLoop（）

或诸如此类的函数可以明显看出

我认为，即使是你通过物体相互拉动来模拟重力的例子本身也没有错。你必须确保信息（即物体被加速并稍微移动）的结果是发生了一些事情您将获得基本公式的粗略离散化。您希望检查碰撞，以使您的模型更完整：-）

---

使用此模型需要程序中一定程度的并发性，以确保消息按正确的顺序处理。

在实际实现中，没有无限循环，而是无限间接递归-

A（）

调用

B（）

，

B（）

调用

C（）

和在某些分支上

C（）

再次调用

A（）

。在您的示例中，如果

Appliance

发送

GetWater

，

Valve

立即发送

HeresYourWaterSir

，并且

Appliance

的

处理程序出于任何原因再次发送
GetWater
，将开始无限间接递归

是的，你是对的，在某些情况下问题可能会发生