В ООП, если объекты посылают друг другу сообщения, не будет ли легко происходить бесконечный цикл?

Question

В статье Apple об объектно-ориентированном программировании изображены объекты, отправляющие сообщения друг другу.Таким образом, Appliance может отправить сообщение на Valve, в котором говорится, что он запрашивает воду, а объект Valve может затем отправить сообщение на Appliance для "подачи воды".

(дляотправить сообщение на самом деле вызывает метод другого объекта)

Так что мне интересно, не вызовет ли это какой-то тонкий бесконечный цикл, который даже программист не предвидел?Например, если мы запрограммируем два объекта, каждый из которых притягивает друг друга под действием силы тяжести, то есть один посылает другому объекту, что существует сила «притяжения», и вызывается метод другого объекта, и, в свою очередь,отправляет сообщение первому объекту, и они уходят в бесконечный цикл.Таким образом, если компьютерная программа имеет только 1 процесс или 1 поток, она просто войдет в бесконечный цикл и никогда не будет запускать что-либо еще в этой программе (даже если два объекта, наконец, сталкиваются друг с другом, они все равно продолжают тянуть друг друга).Как эта парадигма программирования работает в действительности, чтобы предотвратить это?

Обновление: Это бумага Apple: http://developer.apple.com/library/mac/documentation/cocoa/conceptual/OOP_ObjC/OOP_ObjC.pdf

Обновление: длявсе люди, которые просто смотрят на этот очевидный пример и говорят: «Вы ошибаетесь! Программы должны быть конечными, бла-бла-бла», ну, я стремлюсь к тому, что, если есть сотни или тысячи объектов, и они посылают каждыйдругие сообщения, и при получении сообщения они, в свою очередь, могут отправлять другие сообщения другим объектам.Тогда как вы можете быть уверены, что не может быть бесконечного цикла, и программа не может идти дальше.

С другой стороны, для людей, которые сказали, что "программа должна быть конечной", ну, как насчетпростая программа с графическим интерфейсом?У него есть цикл обработки событий, и это бесконечный цикл, который запускается, пока пользователь явно не попросит программу остановиться.А как насчет программы, которая продолжает искать простые числа?Он может продолжать поиск (с BigNum, например, в Ruby, так что для целого числа может быть любое количество цифр), поэтому программа просто написана, чтобы продолжить работу, и записать следующее большее простое число на жесткий диск (или записатьНа жесткий диск один раз в миллион раз он находит большее простое число - поэтому он находит 1 миллион простых чисел и записывает эту миллионную на жесткий диск, а затем продолжает искать следующий миллион простых чисел и записывает 2 миллиона на жесткий диск(напишите только 1 число, а не 1 миллион из них.) Ну, для компьютера с 12 ГБ или ОЗУ и 2 ТБ жесткого диска, может быть, вы скажете, что программе может потребоваться 20 лет, чтобы превзойти возможности компьютера, когда это сложнодиск заполнен или когда 12 ГБ ОЗУ не могут вместить все переменные (может быть, миллиард лет, что целое число не помещается в 1 ГБ ОЗУ), но что касается программы, она просто продолжает работать, если только менеджер памятине может выделить другой BigNum, или жесткий диск заполнен, что исключениевызывается, и программа принудительно останавливается, но программа написана так, чтобы работать бесконечно.Так что не все программы ДОЛЖНЫ быть написаны, чтобы быть конечными.

Answer 1

Почему Appliance должен постоянно запрашивать воду?
Почему Valve бомбардировать Appliance, говоря, что вода предоставляется?

Теоретически - это может создать бесконечный цикл, но вПрактика - все сводится к правильному моделированию Ваших объектов.

Appliance должен отправить ICanHasWater сообщение только один раз, дождаться ответа, получить воду или получить ответ, что вода не может быть предоставлена ​​или будет в будущем, когда Applicance может попытаться запросить воду один разснова.

, поэтому вместо этого я вошел в пример с 2 объектами и гравитацией.

Бесконечный цикл вычисления гравитационных эффектов между объектами произойдет, только если вы запустите эторасчет по расчету.

Я думаю, что общий подход состоит в том, чтобы ввести концепцию Time и рассчитать гравитацию для конкретного TimeFrame, а затем перейти к следующему для следующего раунда расчета.Таким образом, ваш World будет контролировать поток между TimeFrames, и ваше приложение может сделать что-то более полезное, чем бесконечные вычисления гравитационных эффектов.

Answer 2

Без ООП так же просто непреднамеренно создавать бесконечные циклы, возможно, используя императивные языки программирования или функциональное программирование.Таким образом, я не вижу, что особенного в ООП в этом случае.

Если вы думаете о своих объектах как об актерах, отправляющих друг другу сообщения, не обязательно неправильно идти в бесконечный цикл.Инструментарий GUI работает таким образом.В зависимости от используемого языка программирования это становится очевидным при обращении к toolKit.mainLoop() или тому подобному.

Я думаю, что даже ваш пример моделирования гравитации объектами, тянущими друг друга, сам по себе не является неправильным.Вы должны убедиться, что что-то происходит в результате сообщения (т.е. объект ускоряется и немного движется), и вы получите грубую дискретизацию основных формул.Тем не менее, вы хотите проверить наличие коллизий, чтобы сделать вашу модель более полной: -)

Использование этой модели требует некоторого уровня параллелизма в вашей программе, чтобы гарантировать, что сообщения обрабатываются в правильном порядке.

Answer 3

В реальных реализациях нет бесконечного цикла, вместо этого есть бесконечная косвенная рекурсия - A() вызывает B(), B() вызывает C(), а в некоторых филиалах C() снова вызывает A().В вашем примере, если Appliance отправляет GetWater, Valve отправляет HeresYourWaterSir немедленно и обработчик Appliance из HeresYouWaterSir по какой-либо причине отправляет GetWater снова - бесконечная косвенная рекурсия начнется.

Так что да, вы правы, в некоторых случаях могут возникнуть проблемы.Парадигма ООП сама по себе не защищает от этого - она ​​зависит от разработчика.