Метод статической объектной декомпозиции программных систем (SOD)
Новый взгляд на компонентные технологии

Здравствуйте bosm, Вы писали:

B>Метод статической объектной декомпозиции программных систем (SOD)
B>Новый взгляд на компонентные технологии

"Новый взгляд на компонентные технологии" : такую бы статью да лет так 10 назад. А то я вот ещё .NET знаю, на основе которого компонентное программирование расцветает бурным цветом.
А что касается 1 статьи, то дайте мне пожалуйста кусок кода, который это реализует, а то что-то уж больно всё теоретично и IMHO на практике работать не будет, а если и будет, то по сложности превзойдёт COM и .NET вместе взятые.

Здравствуйте Mishka, Вы писали:

M>"Новый взгляд на компонентные технологии" : такую бы статью да лет так 10 назад. А то я вот ещё .NET знаю, на основе которого компонентное программирование расцветает бурным цветом.

Обе статьи об одном и том-же разными словами. Причем тут .NET не очень ясно... Я говорю о локальной компонентной технологии, а не о распределенных вычислениях, сервисах и иже с ними (хотя она может и должна будет потом использована в этих областях). Как я подчеркивал в статьях, все т.н. "компонентные технологии" подразумевает повторное использование компонентов в неких алгоритмических языках. В случае SOD алг. язык не нужен, хотя и может быть использован. Что-то я такого в .NET не припомню...

M>А что касается 1 статьи, то дайте мне пожалуйста кусок кода, который это реализует, а то что-то уж больно всё теоретично и IMHO на практике работать не будет, а если и будет, то по сложности превзойдёт COM и .NET вместе взятые.

У клиента — public member умный указатель, который называем "клиентский разъем". У сервера — public member умный указатель, который называем "серверный разъем". Перегружаем операцию "какую угодно" для присвоения клиентскому разъему значения серверного. Вот так все просто, и никаких .NETов не надо... Все происходит в рамках одного приложения (хотя это не имеет особого смысла "в рамках одного приложения")

B>Обе статьи об одном и том-же разными словами. Причем тут .NET не очень ясно... Я говорю о локальной компонентной технологии, а не о распределенных вычислениях, сервисах и иже с ними (хотя она может и должна будет потом использована в этих областях). Как я подчеркивал в статьях, все т.н. "компонентные технологии" подразумевает повторное использование компонентов в неких алгоритмических языках. В случае SOD алг. язык не нужен, хотя и может быть использован. Что-то я такого в .NET не припомню...

А причём там Java и COM? Java — это язык программирования, COM — это способ написания программ [Роджерсон], .NET — это Framework, или виртуальная операционная система[Gates]. Ничего общего нет, а компонентная парадигма программирования заложена только в COM, CORBA и ещё что-то в .NET только я названия точного не помню.
Теперь о таких статических компонентах. Они уже и сейчас есть: ActiveX называются. В любом случае Вам придётся где-то хранить описание интерфейса, так что вернётесь к IDL или придумаете что-то своё, результат один. Далее: предположим у Вас есть уйма готовых компонент, из них Вы собираете программу. Программа — это некий исполняемый файл. То есть либо Вам надо его компилировать, либо иметь готовое host-приложение, то есть всё равно надо что-то да писать на алгоритмическом языке, по меньшей мере скрипт сборки. Далее: сами компоненты друг с другом общаться не будут, даже имея для этого интерфейс, то есть кто-то должен "толкать" их к взаимодействию посредством алгоритмического языка.
В любом случае то, что описано как SOD уже нашло отражение в так называемых Web Services.

А .NET — это как раз и есть огромный набор готовых классов (класс есть компонент, но не наоборот), бери и собирай готовое приложение... на C#, например. Очень милый язык. Так почему же люди все не бросаются в .NET, где вроде бы столько всего вкусного (одна работа с XML чего стоит, легко и просто, не то что используя MSXML)? А ответ простой — никто не хочет иметь дело с компонентами третьих сторон. "Ну не нравится мне ваш tab control!!!" — и это ещё только начало. Так что теория это всё, теория...

B>У клиента — public member умный указатель, который называем "клиентский разъем". У сервера — public member умный указатель, который называем "серверный разъем". Перегружаем операцию "какую угодно" для присвоения клиентскому разъему значения серверного. Вот так все просто, и никаких .NETов не надо... Все происходит в рамках одного приложения (хотя это не имеет особого смысла "в рамках одного приложения")

Я бы Вам советовал прочитать книгу Роджерсона "Основы COM" он там на полном серьёзе говорил, что если б у него был стыковочный модуль (интерфейс) на крыше дома (сервер), то он мог состыковаться с советской станцией Мир (клиент) и он прав. А зачем это нужно, если нет чего-то что нужно было бы передавать через этот стыковочный модуль?
То есть Вы решаете проблему стыковки, но не проблему взаимодействия. Его кто-то должен будет писать, так что вернёмся к тому что имеем.

И напоследок: Ваша идея напомнила мне идею множественного наследования — много классов, наследуем, получаем класс с обобщённой функциональностью. Теоретически верно, практически — нет. Есть класс для записи событий в log, есть класс для взаимодействия в базой данных, есть класс для обработки данных. Унаследовав от всех трёх, мы не получим класс, который обрабатывает данные их БД и заносит результаты в log.

Здравствуйте bosm, Вы писали:

B>Метод статической объектной декомпозиции программных систем (SOD)
B>Новый взгляд на компонентные технологии

Прочитал "Метод статической объектной декомпозиции программных систем (SOD)" и самого метода не увидел, ну нет там его... Если бы Вы действительно открыли такой метод — это был бы прорыв, сейчас же в статье идёт речь как соединить уже кем-то разбитую на компоненты систему. Приведу пример из геометрии: есть известная задача про квадрат, который надо разрезать на определённое количество частей и из этих частей составить треугольник. Вот метод показывал бы как разрезать на части и сложить новую фигуру, то что в Вашей статье — как скрепить швы, что не даёт знаний о том как решать такие задачи. Т.е. на вопрос: "Как разрезать квадрат, чтобы из частей можно было собрать треугольник?" в статье даётся ответ: "А места срезов мы склеим "Моментом"!".

Извините, сегодня основное внимание я уделил обсуждению на zdnet (уж очень там распалился народ). Завтра постараюсь ответить здесь. Скажу только, что на rsdn критика более конструктивна... и терпима . ;)

Здравствуйте bosm, Вы писали:

B>Обе статьи об одном и том-же разными словами. Причем тут .NET не очень ясно... Я говорю о локальной компонентной технологии, а не о распределенных вычислениях, сервисах и иже с ними (хотя она может и должна будет потом использована в этих областях). Как я подчеркивал в статьях, все т.н. "компонентные технологии" подразумевает повторное использование компонентов в неких алгоритмических языках. В случае SOD алг. язык не нужен, хотя и может быть использован. Что-то я такого в .NET не припомню...

Не знал, да ещё и забыл Не в обиду. Просто .NET зиждется на компонентной модели, он даже её не реализует, а именно на ней построен. Поэтому, советую внимательнее ознакомиться с субъектом.

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.

На это уже ответил в zdnet

VVV>Прочитал "Метод статической объектной декомпозиции программных систем (SOD)" и самого метода не увидел, ну нет там его... Если бы Вы действительно открыли такой метод — это был бы прорыв, сейчас же в статье идёт речь как соединить уже кем-то разбитую на компоненты систему. Приведу пример из геометрии: есть известная задача про квадрат, который надо разрезать на определённое количество частей и из этих частей составить треугольник. Вот метод показывал бы как разрезать на части и сложить новую фигуру, то что в Вашей статье — как скрепить швы, что не даёт знаний о том как решать такие задачи. Т.е. на вопрос: "Как разрезать квадрат, чтобы из частей можно было собрать треугольник?" в статье даётся ответ: "А места срезов мы склеим "Моментом"!".

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

Спасибо.

Читая отзывы в zdnet я с огорчением понял, что неправильно написал статью. Как кто-то хорошо там заметил, слова "Java", "COM", "компонентная технология" оказались "красными тряпками", завесившими основную идею. Ну что-ж, буду учиться на своих ошибках.
Основная идея статей: как приоткрыть пользователю структуру программной системы, но сделать это наиболее безопасным и интуитивно понятным способом — не показывая кода. Поэтому основная идеологема звучит так:
"детали, соединенные посредством разъемов".
Остальное — рассказ о том, как органично описать понятие "разъем" с точки зрения программиста, и как предоставить это описание пользователю.
Целью является создание некой визуальной среды, позволяющей пользователю просматривать и изменять статическую структуру системы, возможно даже во время ее работы. Конечно, это приведет к слиянию системы исполнения с системой "сборки". Но давайте подумаем: такое слияние уже существует, только в "плоском" виде: мы устанавливаем кодек или плагин, но видим его лишь в списке установленных компонентов системы. Я предлагаю показать некоторым категориям пользователей (в смысле "не программистов") истинное место этого кодека, плагина, фильтра, файла и т.п. в рабочей программной системе.

Здравствуйте IT, Вы писали:

IT>Не знал, да ещё и забыл Не в обиду. Просто .NET зиждется на компонентной модели, он даже её не реализует, а именно на ней построен. Поэтому, советую внимательнее ознакомиться с субъектом.

Что, увидели знакомое слово "компонент"? Ну-ну. Ассоциативное мышление полезно, когда оно к месту.

Здравствуйте bosm, Вы писали:

IT>>Не знал, да ещё и забыл Не в обиду. Просто .NET зиждется на компонентной модели, он даже её не реализует, а именно на ней построен. Поэтому, советую внимательнее ознакомиться с субъектом.

B>Что, увидели знакомое слово "компонент"? Ну-ну. Ассоциативное мышление полезно, когда оно к месту.

Увидел вот это:

Обе статьи об одном и том-же разными словами. Причем тут .NET не очень ясно... Я говорю о локальной компонентной технологии, а не о распределенных вычислениях, сервисах и иже с ними (хотя она может и должна будет потом использована в этих областях). Как я подчеркивал в статьях, все т.н. "компонентные технологии" подразумевает повторное использование компонентов в неких алгоритмических языках. В случае SOD алг. язык не нужен, хотя и может быть использован.

В завершении чего это:

Что-то я такого в .NET не припомню...

Так вот. Я даже не буду разбирать здесь сам текст статьи и приводить цитаты, т.к. дилетантизмом там начинает попахивать с первого же предложения. Что касается "Вашей" интертрепации термина "компонентные технологии", то это Ваше личное дело, так сказать Ваше личное "особое мнение". И тем не менее, повторюсь ещё раз. Прежде чем о говорить о предмете, желательно повнимательнее с ним ознакомится. Это касается и .NET и COM и Java и собственно термина "компонентные технологии".

IT>Так вот. Я даже не буду разбирать здесь сам текст статьи и приводить цитаты, т.к. дилетантизмом там начинает попахивать с первого же предложения.

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

IT>Что касается "Вашей" интертрепации термина "компонентные технологии", то это Ваше личное дело, так сказать Ваше личное "особое мнение". И тем не менее, повторюсь ещё раз. Прежде чем о говорить о предмете, желательно повнимательнее с ним ознакомится. Это касается и .NET и COM и Java и собственно термина "компонентные технологии".

Про .NET в статье ни слова. Ни в той, ни в другой. Что же касается того, что моя основная идея ничего общего с .NET не имеет — остаюсь на своем. COM и Java приведены для сравнения. Т.е. я говорю о том, что они не приспособлены для выполнения той функции, которую имею в виду я — обеспечение безопасного доступа пользователей к структуре программной среды. Но от них это и не требовалось.

Здравствуйте bosm, Вы писали:

B>Про .NET в статье ни слова. Ни в той, ни в другой. Что же касается того, что моя основная идея ничего общего с .NET не имеет — остаюсь на своем. COM и Java приведены для сравнения. Т.е. я говорю о том, что они не приспособлены для выполнения той функции, которую имею в виду я — обеспечение безопасного доступа пользователей к структуре программной среды. Но от них это и не требовалось.

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

Ok. Ты сам этого захотел (давай на "ты", т.к. обращение на "Вы" у нас на сайте обычно не предвещает ничего хорошего ;) )

Пройдёмся по статье.

>КОММЕНТАРИЙ — Начну с того, что на сегодняшний день я не знаю других серьезных кандидатов на звание «компонентной технологии», кроме COM и Java.

Впервые вижу в одном ряду COM и Java. Я понимаю COM и Corba, в крайнем случае объектная модель Java, но не так вот запросто...

Насчёт "я не знаю" — посмотри на .NET. На сегодня эта технология является фаворитом в ряду технологий, который имеют отношение к термину "компонентный". Насколько она впереди и как далеко — это другой вопрос.

>COM явно разрабатывалась для нужд интерпретаторов, а именно Visual Basic, что видно уже из устройства базового интерфейса IUnknown.

Вот и я говорю, книжки надо читать. VB хоть и понимает IUnknown, но больше любит IDispatch. Интерпретаторы или, в простонародье, скриптовые языки вообще IUnknown на дух не переносят.

>Java обладает чертами компонентности сама по себе и для самой себя. В обоих случаях речь идет о компонентах, которые будут использованы потом в каких-то алгоритмических языках для создания программ.

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

>Другие возможности использования компонентов никому в голову не приходят и в расчет не берутся. Понятия «компонентности» и «повторного использования» (reusing) сливаются и становятся неразличимы.

Я бы подчеркнул — уже не приходят. Обо всех этих идеях я читал ещё лет пять-шесть назад в первых книжках про COM и ActiveX технологии. И в каждой говорилось о том какое это благо — строить программные комплексы из готовых компонент, и скоро юзерам совсем ничего не останется делать, кроме как покупать готовые кирпичи и строить из них себе дома по вкусу и возможностям.

>Между тем хотелось бы когда-нибудь увидеть воплощение интуитивного восприятия словосочетания «компонентная технология» как способа построения систем из компонентов, соединенных между собой посредством разъемов. Современное программирование давно доросло до понимания того, как реализовать подобную идею. Роль разъема может взять на себя интерфейс, т.е. абстрактный виртуальный класс, ...

Современное программирование уже перерасло эту идею. Идею может и хорошую, но на практике не состоявшуюся по банальным причинам. Разъёмы, понимаишь, делают одни, а использут другие. Первые делают ширпотреб, а вторым нужен индпошив. Вторые просят первых вот здесь подлатаь, а третьим начинает жать, на четвёртых висеть, пятые посылают всех и идут искать других первых или клепать всё сами. Вот такие разъёмы получаются, интерфейсы так сказать.

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

Вот те раз. В недрах Microsoft бьются красные комиссары в бессильной злобе, чтобы раз и навсегда похоронит реестр Windows как зло мирового масштаба, а мы в него разъёмы будем запихивать.

>Попробуем вообразить себе более подробно реализацию такой системы. Пусть для каждого компонента указано, клиентом каких интерфейсов он может (или должен) являться. Назовем такие «пустые места», т.е. требуемые интерфейсы, клиентскими разъемами. Если компонент предоставляет какие-либо интерфейсы для внешнего использования, они могут быть названы серверными разъемами. Так сами собой появляются правила соединения разъемов:

А если я, как клиен, реализую разъём, но никто не захочет сделать для него сервер, шош мне так вот стоять со своим "пустым местом"? А ведь мне нужен не один разъём, да и завтра понадобятся более новые, а старые нужно будет немного модифицировать...

[фантазии поскипаны]

>Вот как я представляю себе, с учетом новой компонентной технологии, многоуровневую систему разработки приложений и программных систем будущего:

[глубинные познания в построении программных систем тоже]

>В наше время зачатки такого подхода уже видны в таких популярных инструментах, как Delphi или C++ Builder. Например, там можно собрать простое приложение для работы с базами данных, не написав при этом ни строчки кода.

Это точно, компонентней некуда.

>Автор работает программистом с 1995 года; специализируется на промышленных системах и системах реального времени.

В общем, статья вполне доходчиво разъяснила мне, что автор начинает наконец-то понимать назначение компонентной модели. И это здорово :)

А я уж боялся что никто ничего толкового так и не скажет.

IT>Впервые вижу в одном ряду COM и Java. Я понимаю COM и Corba, в крайнем случае объектная модель Java, но не так вот запросто...

Еще раз повторю, что согласен. Смысл был таков: они (оба) предоставляют основу для построения компонентных технологий.

IT>Насчёт "я не знаю" — посмотри на .NET. На сегодня эта технология является фаворитом в ряду технологий, который имеют отношение к термину "компонентный". Насколько она впереди и как далеко — это другой вопрос.

ОК, но я пока не вижу активного использования .NET. Много разговоров. Подождем, посмотрим.

IT>... и программных систем, состоящих из комплекса программ, которые при грамотном проектировании, могут быть построены из отдельных повторно-используемых компонент.

С чем я не спорю.

IT>Я бы подчеркнул — уже не приходят. Обо всех этих идеях я читал ещё лет пять-шесть назад в первых книжках про COM и ActiveX технологии. И в каждой говорилось о том какое это благо — строить программные комплексы из готовых компонент, и скоро юзерам совсем ничего не останется делать, кроме как покупать готовые кирпичи и строить из них себе дома по вкусу и возможностям.

Вот в книжках по COM и ActiveX и не следовало этого писать. Эти штуки не содержат информацию о том, как открыть структуру приложения пользователям. Поэтому там это явная глупость. Я же предлагаю простой механизм.
И потом: модель (аналогичную моей) никто не предложил. А почему? Ответ прост: все начали зарабатывать деньги на COM. И хорошо, что начали. Я предлагаю (на секунду) приостановиться и пофантазировать как это можно было бы сделать толково (лет пять-шесть как).

IT>Современное программирование уже перерасло эту идею. Идею может и хорошую, но на практике не состоявшуюся по банальным причинам. Разъёмы, понимаишь, делают одни, а использут другие. Первые делают ширпотреб, а вторым нужен индпошив. Вторые просят первых вот здесь подлатаь, а третьим начинает жать, на четвёртых висеть, пятые посылают всех и идут искать других первых или клепать всё сами. Вот такие разъёмы получаются, интерфейсы так сказать.

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

IT>Вот те раз. В недрах Microsoft бьются красные комиссары в бессильной злобе, чтобы раз и навсегда похоронит реестр Windows как зло мирового масштаба, а мы в него разъёмы будем запихивать.

Уже писал про это в zdnet: если реестр не нравится, можно выразиться по другому: информация об иерархии должна быть глобальна по отношению к системе исполнения. Как это может быть реализовано — сейчас не так важно. Глубоко уважаю бьющихся комиссаров.

IT>А если я, как клиен, реализую разъём, но никто не захочет сделать для него сервер, шош мне так вот стоять со своим "пустым местом"? А ведь мне нужен не один разъём, да и завтра понадобятся более новые, а старые нужно будет немного модифицировать...

Нет, не так. Вы сделали систему со всеми клиентами и серверами и открыли ее структуру. Кто хочет — пусть пишет новые клиенты или новые сервера. Или вы сами напишете новые клиенты и сервера и предложите их пользователю (например, сисадмину).

IT>В общем, статья вполне доходчиво разъяснила мне, что автор начинает наконец-то понимать назначение компонентной модели. И это здорово

Спасибо на добром слове

Здравствуйте bosm, Вы писали:

B>Никто не заставляет программистов использовать только чьи-то готовые компоненты (и сейчас, и в существующих объектных моделях). В предлагаемой модели вообще не обязательно использовать чужие компоненты. Ошибочно понимание ее как модели для разработчика. Это модель для продвинутого пользователя. Она лишь обязывает разработчика представлять результат своего труда в некотором стандартном виде и дает инструменты и способ этого представления.

Модель дает инструменты? Сильно сказано.

IT>>Вот те раз. В недрах Microsoft бьются красные комиссары в бессильной злобе, чтобы раз и навсегда похоронит реестр Windows как зло мирового масштаба, а мы в него разъёмы будем запихивать.

B>Уже писал про это в zdnet: если реестр не нравится, можно выразиться по другому: информация об иерархии должна быть глобальна по отношению к системе исполнения. Как это может быть реализовано — сейчас не так важно. Глубоко уважаю бьющихся комиссаров.

IT>>А если я, как клиен, реализую разъём, но никто не захочет сделать для него сервер, шош мне так вот стоять со своим "пустым местом"? А ведь мне нужен не один разъём, да и завтра понадобятся более новые, а старые нужно будет немного модифицировать...

B>Нет, не так. Вы сделали систему со всеми клиентами и серверами и открыли ее структуру. Кто хочет — пусть пишет новые клиенты или новые сервера. Или вы сами напишете новые клиенты и сервера и предложите их пользователю (например, сисадмину).

Все это так или иначе уже реализовано в .NET. Там действительно есть инструменты для представления результатов своего труда для других (как пользователей, так и разработчиков, хотя последние тоже являются пользователями )

Здравствуйте Андрей, Вы писали:

А>Все это так или иначе уже реализовано в .NET. Там действительно есть инструменты для представления результатов своего труда для других (как пользователей, так и разработчиков, хотя последние тоже являются пользователями )

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

Здравствуйте bosm, Вы писали:

B>Здравствуйте Андрей, Вы писали:

А>>Все это так или иначе уже реализовано в .NET. Там действительно есть инструменты для представления результатов своего труда для других (как пользователей, так и разработчиков, хотя последние тоже являются пользователями )

B>Модель "деталь-разъем" возможно применить не только в рамках какой-либо операционной системы, но и вне ее, и даже по отношению к ядру операционной системы. Можно осуществить статическое разбиение операционной системы и сделать ее части легко заменяемыми. Это уже существует — например, в виде модулей Линукс, — но опять же в "плоском виде". А не хотите "в плоском" — лезьте в исходный код.
B>Поэтому я все-таки не стал бы сравнивать модель "деталь-разъем" с .NET Это гораздо более простая и "базисная" вещь.

Ну-ну, меня от модулей Линукс наизнанку выворачивает (когда один из модулей не подключен и система просто отказывается загружаться) — это, кстати, плохой пример. Модули в Линукс были введены относительно недавно, отсюда и проблемы с ними, а изначально модель ОС Линукс была монолитной. Но, видимо, Вы не читатель, Вы писатель...

Здравствуйте Андрей, Вы писали:

А>Ну-ну, меня от модулей Линукс наизнанку выворачивает (когда один из модулей не подключен и система просто отказывается загружаться) — это, кстати, плохой пример.

Вот-вот, для избежания таких ситуаций я и предлагаю модель "деталь-разъем", в которой клиентский разъем сразу закричит, если ему не хватит серверного. Это первое. Второе — модули Линукса, тем не менее, активно используются, например в моей любимой RTLinux. И там без них никак, поверьте мне.

А>Модули в Линукс были введены относительно недавно, отсюда и проблемы с ними, а изначально модель ОС Линукс была монолитной. Но, видимо, Вы не читатель, Вы писатель...

Сказано несколько эмоционально, но близко к истине.

Здравствуйте bosm, Вы писали:

B>Основная идея статей: как приоткрыть пользователю структуру программной системы, но сделать это наиболее безопасным и интуитивно понятным способом — не показывая кода. Поэтому основная идеологема звучит так:
B>"детали, соединенные посредством разъемов".
B>Остальное — рассказ о том, как органично описать понятие "разъем" с точки зрения программиста, и как предоставить это описание пользователю.
B>Целью является создание некой визуальной среды, позволяющей пользователю просматривать и изменять статическую структуру системы, возможно даже во время ее работы. Конечно, это приведет к слиянию системы исполнения с системой "сборки". Но давайте подумаем: такое слияние уже существует, только в "плоском" виде: мы устанавливаем кодек или плагин, но видим его лишь в списке установленных компонентов системы. Я предлагаю показать некоторым категориям пользователей (в смысле "не программистов") истинное место этого кодека, плагина, фильтра, файла и т.п. в рабочей программной системе.

Знаете, когда-то мне было откровение при просмотре в OLEView WORD.OLB (или WORD.IDL). Привожу для наглядности следующий фрагмент:

[
  uuid(00020906-0000-0000-C000-000000000046),
  helpcontext(0x0000096b)
]
coclass Document {
    [default] interface _Document;
    [default, source] dispinterface DocumentEvents;
};

Я-то наивный действительно думал, что Document имеет ОДИН интерфейс (IUnknown и Idispatch не включаю из-за их общности) , пока на практике не убедился в обратном .

Но в принципе никто не мешает создателю СОМ-объекту описать ВСЕ его интерфейсы в IDL для задействования в некой визуальной среде, но никто так не делает. (И, наверное, есть причины для этого.)

Поэтому всегда так будет, ИМХО, что используемый компонент нельзя будет заменить на другой компонент или улучшить его собственной надстройкой, потому что фактически требования одного компонента ("серверные разъемы") и другого ("клиентские разъемы") не будут полностью специфицированы. Как бы нам этого не хотелось.