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

Значит, в отличие от чисто объектно ориентированного подхода, кроме объектов предлагается внести понятие "среды", которая тоже "живая" и обладает определенными свойствами.

Среда может реализовывать "отношения" между объектами, занимаясь попутно синхронизацией их работы через рассылку сигналов (сигналы может посылать только "среда").

Отношение между объектами бывает двух типов:

1) Обмен данными - передача структурированной информации в том духе как это происходит с SQL серверами и их клиентами
2) Управление - передача разрешительных-запретительных логических состяоний, которые могут по дороге конкурировать между собой (от различных объектов) и вступать в логическое (булево) взаимодействие.

Объекты в отличие от ООП опять же стандартизируются и отличаются только внутренностями (функцией).

Вот такой... как мне думается - лисапедик.

Gluk (Kazan)что мешает представить "среду" объектом ?

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

Диез Drown Gluk (Kazan)что мешает представить "среду" объектом ?

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

По описанию очень похоже на JavaEE, например. Или на некий интеграционный продукт, типа BizTalk.

Впрочем, если вы разработаете некую спецификацию на эту среду выполнения, то есть:

- описание "среды" с технологической точки зрения
- описание формата коннекторов для обмена данными между "средой" и внешними системами
- интерфейс взаимодействия внутренних объектов и "среды"
- язык для задания правил обработки управляющих сигналов

и выложите сюда, думаю, это будет интересно.

А что и выложу. Ждите.

Gluk (Kazan) нет в нем ничего особенного

объект как объект

Да, без необходимости не надо ничего плодить. Но не нужно доводить указанный принцип до абсурда все таки :-)

Нам, русским например ваапще ничего не надо. Кошечкам собачка еще меньше. Сущности не плодятся потому что находятся другие решения.

Про современный способ создания программ с использованием ООП в том чсиле в плохом смысле сегодня говорится много.
Например существует такая проблема - когда изменение некоторых принципов функционирования системы затрагивает отдельные аспекты работы КАЖДОГО объекта (например, синхронизация, распределенное выполение, поддержка сети и так далее). Эта проблема родила принцип аспектно-ориентированного программирования.
Предлагаемая архитектура тоже решает эту проблему, но иначе. Те самые - общие аспекты, который в ООП подходе заставляют переписывать (дописывать) всю библиотеку, в данном варианте стандарта архитектуры могут быть реализованы изменением только одного, при этом специального объекта - среды.

Gluk (Kazan)А по делу (без БЛА БЛА БЛА про русских кошечек и собачег) ?

Какие преимущества дает такой подход ?
Как он решает существующие проблемы проектирования ?
Какие проблемы ??? ;)

А то уж очень сильно напоминает: "А не построить ли мост отсюда аж до самой Москвы"
Да, извиняюсь про антирусские настроения. Сам не пойму че ляпнул.

Ну так вот - по делу.

1) Сначала скажу пару слов о способе реализации "объектов", да и самой среды. Способов может быть 2, как это и принято сегодня:
а) универсальный, откомпилированный и закрытый программный объект, способный настраиваться и менять свое поведение в зависимости от входных "метаданных". Ну например, объект (класс)выполняющий запрос к базе данных, управляемый подаваемой на "вход" строкой - SQL запросом.
При этом в "предложенном подходе" параметризированный SQL запрос - это метаданное, определяющее конечную функцию и конкретизирующую объект из общего класса, до работающего экземпляра в системе, а параметры SQL запроса, которые могут передаваться этому экземпляру, это содержательная часть указанных элементарных "отношений", реализуемых в runtime.

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


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

- изменением свойств "среды" (например, настройкой триггеров на некие события - по современному - аспектов) или передачей среде неких параметров (например tracelevel) можно добиватся того же чего добивается аспектно-ориентированное программирование. тогда в чем же разница спросите вы. разница в том, что среда это и аспекты тоже но при этом шире чем аспекты.
например среда может обеспечивать совместимость компонентов, даже при различиях в их интерфейсов, кроме того:

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

Gluk (Kazan)Как вариант, действительно познакомиться со SmallTalk
Даже если не понравится в чистом виде, можно почерпнуть какие-то идеи

На счет 2 способов - не Америка. Сегодня только ленивый не скрещивает C++ ый ООП с его же шаблонами

Да не - при чем тут америка. Я ж не собираюсь варится в собственном бульоне.
Просто к тому что придумал приложил уже наработанные способы реализации.

SmallTalk - это другое (почитал).

В SmallTalk сообщение содержит конкретное действие.
Действие (сообщение) должно быть совместимо с объектом.

Тут у меня другое: объект вообще говоря универсален. И сообщения внутри среды обитания он понимает все. А среде передает свои состояния, которые тоже унифицированы для среды и понимаемы ею независимо от объекта.

Я пожже приведу пример функционального вычисленяи через предложенную архитектуру.

Gluk (Kazan) Drownприложил уже наработанные способы реализации.

хиде ?

приклеил, прислюнявил, предложил теоретически...
ну не в камне же высек.

в пункте 1.бэ.

maytonТопик - бред. Никакой конкретики, только переливание из пустого в порожнее.

я же сказал - абстракция.
но мнение - обратную связь - получил :-)
чего и хотел.

со СмолТолком разница сильная - я по крайней мере вижу.
да сигналы и объекты - нечто общее.
но слова одинаковые, а смысл разный.

по пункту 1б - там вообще ничего нового и не планировалось. просто перечислялись два из принятых и весьма распростарненных способа генерации приложений.