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

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

Было бы интересно. Просто для фана, поиграться. А потом, глядишь, и выйдет чего.

UPDATE: всё это называется многоагентными системами. Программировать в них можно вот так например.

То что сейчас будет написано возможно противоречит каким-нибудь принципам "правильного" проектирования ПО, так что будьте осторожны ))

Предлагаемый подход родился в моей голове чтобы упростить доступ к объектам классов вида "синглетон". Кто не в курсе, знайте, что это классы с объектами в единственном экземпляре и временем жизни равным (или примерно равным) времени работы программы. Классический подход предлагает передавать их по цепочкам в виде параметров и хранить в объектах-клиентах посредством агрегации (в виде ссылок). Такой подход похож на прокладывание сетевых проводов, где устройства взаимодействуют лишь с соседями, прямо или косвенно соединёнными проводами. Прокладывать провода или же обеспечивать каждый раз передачу синглетона по иерархии геморно. Поэтому предлагается устроить нечто похожее на wifi-сети в проектируемой объектно-ориентированной системе. Сделать синглетоны доступными всем, посредством статической переменной (метода) - почему бы и нет?

Преимущества заключаются в том, что получить доступ к такому синглетону можно из любого другого класса без всяких параметров. Недостаток заключается в отсутствии контроля за состоянием синглетона, т.к. теперь кто угодно в любой момент времени может его изменить. Чтобы исправить этот недостаток, можно разрешить доступ к синглетону только тем классам, для кого он предназначен. Как же это сделать? В разных языках могут быть свои средства, но всегда можно явно прописать в синглетоне названия конкретных классов, а потом проверять их в методе получения синглетона. Можно также извратиться и сделать что-то вроде системы паролей в своей программе, если других языковых средств нет.

Выгода от этого подхода огромна! Нет гемору с параметрами и ссылками!
Подробности описал в этой статье.