M>А причём там Java и COM? Java — это язык программирования, COM — это способ написания программ [Роджерсон], .NET — это Framework, или виртуальная операционная система[Gates]. Ничего общего нет, а компонентная парадигма программирования заложена только в COM, CORBA и ещё что-то в .NET только я названия точного не помню.
Да, я несколько неудачно начал статью в zdnet, но Вы, видимо, уже прочитали мое мнение. Вы правы, я имел в виду компонентные модели.
M>Теперь о таких статических компонентах. Они уже и сейчас есть: ActiveX называются. В любом случае Вам придётся где-то хранить описание интерфейса, так что вернётесь к IDL или придумаете что-то своё, результат один.
В том то и дело, что не нужно (для моих целей) хранить информацию о внутренней структуре интерфейса в IDL и иже с ним. Нет, ничего придумывать не надо. Достаточно хранить информацию об иерархии, которая будет говорить о совместимости разъемов. Причем не обязательно открывать иерархию именно такой, какой она является на самом деле: достаточно открыть ту ее часть, которая говорит о совместимости.
M>Далее: предположим у Вас есть уйма готовых компонент, из них Вы собираете программу. Программа — это некий исполняемый файл. То есть либо Вам надо его компилировать, либо иметь готовое host-приложение, то есть всё равно надо что-то да писать на алгоритмическом языке, по меньшей мере скрипт сборки.
Совершенно верно, есть лишь одно "но" — алгоритмический язык в моей модели не нужен.
M>Далее: сами компоненты друг с другом общаться не будут, даже имея для этого интерфейс, то есть кто-то должен "толкать" их к взаимодействию посредством алгоритмического языка.
С помощью языка, возможно визуального (графического), но не обязательно алгоритмического.
M>В любом случае то, что описано как SOD уже нашло отражение в так называемых Web Services.
Не нашло (в таком виде, как я описываю). Докажите, что нашло :) . Кроме того, не SOD главное, а то, что с его помощью я предлагаю сделать.
M>А .NET — это как раз и есть огромный набор готовых классов (класс есть компонент, но не наоборот), бери и собирай готовое приложение... на C#, например. Очень милый язык. Так почему же люди все не бросаются в .NET, где вроде бы столько всего вкусного (одна работа с XML чего стоит, легко и просто, не то что используя MSXML)? А ответ простой — никто не хочет иметь дело с компонентами третьих сторон. "Ну не нравится мне ваш tab control!!!" — и это ещё только начало. Так что теория это всё, теория...
Хорошо, другое сравнение. В bash мы пишем
sort sample_file | cat -n > sample_numa
Я предлагаю перевести подобную идеологию на уровень компонентов. В этом случае сначале создается компоненты класса sort cat и file, например так, на псевдоязыке:
new sort s;
s.file = "sample_file"; new cat c;
c.numbering = true; new file f("sample_numa");
Теперь соединение разъемов и запуск:
s.output >> c.input;
c.output >> f.input; run s;
В такой схеме output будут клиентскими разъемами (т.е. "пустыми местами"), а input — серверными.
Замечу, алгоритмами тут не пахнет и может быть легко визуализировано.
M>Я бы Вам советовал прочитать книгу Роджерсона "Основы COM" он там на полном серьёзе говорил, что если б у него был стыковочный модуль (интерфейс) на крыше дома (сервер), то он мог состыковаться с советской станцией Мир (клиент) и он прав. А зачем это нужно, если нет чего-то что нужно было бы передавать через этот стыковочный модуль?
Хорошая книга. Замечание непонятное.
M>То есть Вы решаете проблему стыковки, но не проблему взаимодействия. Его кто-то должен будет писать, так что вернёмся к тому что имеем.
Должен будет писать программист, как и раньше. Пользователь
а) будет видеть статическую структуру
б) будет способен ее изменить
M>И напоследок: Ваша идея напомнила мне идею множественного наследования — много классов, наследуем, получаем класс с обобщённой функциональностью. Теоретически верно, практически — нет. Есть класс для записи событий в log, есть класс для взаимодействия в базой данных, есть класс для обработки данных. Унаследовав от всех трёх, мы не получим класс, который обрабатывает данные их БД и заносит результаты в log.
