我的理解是，面向对象编程提倡对象之间的交互。但据我所知（我学过一点Java），程序有明确的做事路径。像main例程或其他一些函数一样，强制对象使用其方法。
我还读到OOP程序应该类似于现实世界。在现实世界的例子中，猫和狗会在没有外部干预的情况下进行交互。没有人会强迫狗对猫吠叫，但这是"狗"对象的本性。
但是在Java中，对象并没有真正相互交互。有一个main函数指导对象的交互。如果所有对象都可以识别附近的对象（没有其他函数的帮助）并同时运行它们的动作，那不是更好吗？我认为它更像现实世界。
编辑：-@Makoto 是的，我的观点是对象不会自动相互作用。
如果对象可以识别同一附近的其他对象并同时运行（如线程），我们可以更紧密地类似于现实世界，同时对其进行编码以完成我们的工作。
例：-
class Dog {
if you see a cat object in the same place
bark at it.
if you see the owner object
wag your tail.
}
如果像这样，我们可以创建一堆对象并让它们 自动交互 ，程序根本不是线性的。是的，它不同于普通的OOP或函数式编程。但是我们可以达到与现实世界相同的结果，或者我希望如此。
class Dog {
void barkAtCat(Cat c){
c.gotBarkedAt(this);
}
void gotHissedAt(Cat c){
barkAtCat(c);
}
}
class Cat {
void gotBarkedAt(Dog d){
hissAtDog(d);
}
void hissAtDog(Dog d){
d.gotHissedAt(this);
}
}
这里有一个非常简单的例子，说明两个Object"彼此交互"：是的，你必须从"外部"发起交互——因为，毕竟，这不是"现实世界"，而是它的模拟——请参阅@The111、@Sujan和@PelitMamani的答案，了解对此的宝贵想法。
也就是说，这里争论的OO原则是，你可以在程序（Dog和Cat）的Object中对域中对象（狗和猫）的性质和行为进行建模，这可以包括这些对象之间"自动"发生的交互，作为你编码的对象性质的函数。在此示例中，对 barkAtDog() 或 hissAtCat() 的单个调用将导致这两个对象之间的交互无限循环。这显然是一个微不足道的例子，但如果你想象对更复杂的行为和对象之间的关系进行建模，你可以开始想象对更复杂的、涌现的自然现象的模拟，我希望在这个答案中传达的是OO这样做的有用性。
为了响应您的编辑 - 您的直觉认为多线程对于任何此类模拟都是必不可少的。事实上，在许多 Java 类的介绍中，多线程单元末尾的项目是一个非常类似于您描述的模拟。
有趣的哲学问题。只是我的拙见：
-
你不一定被迫创建一个准确的世界副本。你只需要一个对你的业务足够好的模型（我什至不会进入"什么是世界的准确副本"的问题，有些人可能会觉得猫和狗被一些更高的权力控制......
-
关于"独立性"：在一些现实世界的场景中，物体做出独立的决定（例如，你的猫和狗的例子）;在其他场景中，物体是受控的（例如，如果猫和狗是木偶）。关于他们对彼此的了解——如果Java默认让他们都认识对方，那也将无法反映现实世界：如果它们之间有一座小山的猫和狗怎么办？它们相互定位的能力将取决于风的方向（=气味）或其他什么。因此，编程语言必须选择一些简单的默认值，因为他们知道无论他们选择什么默认值 - 他们都不能假设反映所有现实世界的场景。需要额外的编码。
任何类型的编程都隐含地包括一个要遵循的程序和一个编写该程序的程序员。 今天存在的编程并不涉及创造相互玩耍的动物，除非程序员明确定义了游戏类型和每种游戏所需的条件，并将它们包含在他的书面程序中。 他很可能会使用OOP来编写该程序。
你的问题不是关于OOP或Java，而是一般的编程。
你的问题不是关于 O bject Orientated Programing，而是一般的编程和算法。程序只做它被指示做的事情，否则它就不是程序。我们可以想象，像现实世界中的猫和狗之间的互动可以被编程，就像其他任何东西一样。编程是关于将现实世界的算法和属性转换为代码行。
然而，我们现在可以同意，一个真实的物理世界不能仅仅通过编写代码行来创建。也许在未来，随着全息和量子计算的突破，我们将能够用几行代码创造出真正的猫和狗。
我想通过德鲁摩尔的答案再扩展一下。
扩展：有一点需要清除。狗不会对猫自己吠叫。还有一种媒介，狗通过它知道猫在他面前，而媒介是思想或大脑。所以我可以将每个人的大脑与每个人的actionListener()联系起来。在现实世界中，大脑会触发狗吠叫，而在计算机/程序世界中actionListener()会触发狗吠叫。