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


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

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

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

Несколько непонятно. Моя модель как раз и предлагает способ "поверхностной спецификации": <b>требований</b> (клиентские разъемы) и <b>предложений</b> (серверные разъемы). Все остальное — вопрос проектирования.

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

Z>Посмотри/изучи делегаты в .Net. Там не надо ничего наследовать, не надо строить иерархий, достаточно что бы сигнатура метода совпадала. Можешь соединять все и вся в любых мыслимых комбинациях.

см. дискуссию выше, а именно мое сообщение http://www.rsdn.ru/forum/message.asp?mid=35337&amp;only

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

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

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

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

Уважаемый, не трогайте пожалуйста микроядерные ОС, они и без Ваших компонентных технологий хорошо дышат. И если Вы приводите их в пример, то упоминать надо не Linux, а L4.

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

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

B>см. дискуссию выше, а именно мое сообщение http://www.rsdn.ru/forum/message.asp?mid=35337&amp;only
Дискутировать на эту тему можно бесконечно, можно взять структурное программирование 70х, придумать подобие ООП, и бесконечно рассуждать о преимуществах своего метода. Это всего лишь разновидность велосипеда, я не говорю что это плохо, но не замечать этого нельзя. Свои технологии надо сравнивать с технологиями сегодняшнего дня.

M>Уважаемый, не трогайте пожалуйста микроядерные ОС, они и без Ваших компонентных технологий хорошо дышат. И если Вы приводите их в пример, то упоминать надо не Linux, а L4.

Я где-то упомянул микроядерные ОС? Надо же, не заметил. ;)

Z>Дискутировать на эту тему можно бесконечно, можно взять структурное программирование 70х, придумать подобие ООП, и бесконечно рассуждать о преимуществах своего метода. Это всего лишь разновидность велосипеда, я не говорю что это плохо, но не замечать этого нельзя. Свои технологии надо сравнивать с технологиями сегодняшнего дня.

уточню: с близкими технологиями сегодняшнего дня. :)

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

Z>>Дискутировать на эту тему можно бесконечно, можно взять структурное программирование 70х, придумать подобие ООП, и бесконечно рассуждать о преимуществах своего метода. Это всего лишь разновидность велосипеда, я не говорю что это плохо, но не замечать этого нельзя. Свои технологии надо сравнивать с технологиями сегодняшнего дня.

А>уточню: с близкими технологиями сегодняшнего дня.
Я рад что вы правильно меня поняли.

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

B>Метод статической объектной декомпозиции программных систем (SOD)
B>Новый взгляд на компонентные технологии
Нечто подобное этому, естественно, для специфической задачи (обработка данных) реализовано в продукте SAS Enterprize Miner. Вкратце суть там такова: в системе есть набор компонентов, таких как таблица данных, преобразователь данных, построитель регрессии, нейронной сети, генератор отчетов и т.п. Их можно, условно говоря, набросать на форму, соединить линиями со стрелочками, которые представляют потоки данных, и запустить всю систему на исполнение. Поток данных должен всегда начинаться, естественно, из какой-либо таблицы БД. В дальнейшем он разветвляется (т.е. могут применяться различные обработчики данных — например, регрессия и нейросеть), затем снова соединяться (например, для сравнения результатов, полученных разными метдами) и т.п. Никакого "программирования" при этом не требуется, но легко можно реализовывать достаточно сложную обработку данных.
Так что для частных задач предлагаемая технология может весьма успешно применяться.
Однако применение ее в общем случае может вызвать проблемы, решение которых приведет, вероятно, к созданию аналогов скриптовых языков и т.п., от чего, как я понимаю, автор хотел уйти. Кроме уже упомянутых в других сообщениях, можно указать следующие проблемы:
1. Ограничения на входные данные серверов и выходные данные клиентов. Несмотря на то, что соответствующие интерфейсы клиента и сервера могут быть совместимы (по имени и сигнатуре функции — пример из C++), они могут быть несовместимы содержательно, поскольку предусловия методов интерфейса сервера могут не удовлетворяться клиентами. Один из путей обхода этой проблемы — игнорировать ее и готовиться к возникновению run-time ошибок. Другой путь — включить пред- и, возможно, постусловия в описание интерфейса. При увеличении детализации можно придти к тому, что пред- и постусловия будут попросту описывать алгоритм работы метода.
2. Совсем простая проблема. Пользователю, собирающему из компонентов программу, рано или поздно захочется реализовать простейшую логику взаимодействия компонент — вызвать определенный компонент n раз, предпринять какие-то действия в зависимости от результата работы компонента и т.п. Если не пользоваться скриптовыми языками (как используется для этой цели VB в COM), то необходимо вводить компоненты, реализующие эту логику: IF-компонент, FOR-компонент и т.п., но это приведет к ненужному усложнению системы.

Андрей Григорьвев.

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

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

Не надо ждать, надо учить и применять. А ждут пусть другие, те кто хочет быть в хвосте на этом празднике жизни

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

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

Тогда чем в этом случае отличается объектная модель любого приложения из MS Office? Если я хочу, то могу запросто написать нового клиента или сервера для MS Word. Или это опять не то?

IT>Тогда чем в этом случае отличается объектная модель любого приложения из MS Office? Если я хочу, то могу запросто написать нового клиента или сервера для MS Word. Или это опять не то?

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

А>Нечто подобное этому, естественно, для специфической задачи (обработка данных) реализовано в продукте SAS Enterprize Miner.

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

А>Так что для частных задач предлагаемая технология может весьма успешно применяться.

"Технология соединения деталей" — согласен, только для частных. Моя для общих, поскольку статическая декомпозиция может быть применена практически в любых задачах (если задача не проста по структуре).

А>1. Ограничения на входные данные серверов и выходные данные клиентов. Несмотря на то, что соответствующие интерфейсы клиента и сервера могут быть совместимы (по имени и сигнатуре функции — пример из C++), они могут быть несовместимы содержательно, поскольку предусловия методов интерфейса сервера могут не удовлетворяться клиентами. Один из путей обхода этой проблемы — игнорировать ее и готовиться к возникновению run-time ошибок. Другой путь — включить пред- и, возможно, постусловия в описание интерфейса. При увеличении детализации можно придти к тому, что пред- и постусловия будут попросту описывать алгоритм работы метода.

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

А>2. Совсем простая проблема. Пользователю, собирающему из компонентов программу, рано или поздно захочется реализовать простейшую логику взаимодействия компонент — вызвать определенный компонент n раз, предпринять какие-то действия в зависимости от результата работы компонента и т.п. Если не пользоваться скриптовыми языками (как используется для этой цели VB в COM), то необходимо вводить компоненты, реализующие эту логику: IF-компонент, FOR-компонент и т.п., но это приведет к ненужному усложнению системы.

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

"Программа распространяется в виде схемы ее статической декомпозиции".

"Статическое разбиение любой серьезной системы осуществляется всегда и всеми программистами, в меру их разумения. Иногда это разбиение остается в голове, иногда фиксируется с помощью CASE-средства. Все, что я предлагаю — это оставить статическую структуру программы видимой для пользователя и позволить ему изменять эту структуру. Я не предлагаю заставить программистов собирать приложения из купленных\скачанных компонентов, это неестественно (и в статье такое не предлагается). Более естественный путь — программа распространяется в виде "схемы" ее статической декомпозиции."

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

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

Мне кажется, что очень близкой по духу и смыслу к Вам является теория паттерновых сетей Гренандера. Все те же модули и связки.
Теория очень интересная и перспективная (даже наше министерство финансов ее неплохо спонсирует). Правда эта теория пока не применялась для постороения программного обеспечения, но это в силу своей молодости.
В России теорией паттерновых сетей занимается ВнииПвти (http://www.pvti.ru/isl/pattern.htm). У меня там есть знакомые и, если Вы заинтересуетесь, то я обещаю вас свести. Они будут очень благодарны и счастливы, если кто-то хотя бы прикинет возможность использования паттерновых сетей для проектирования программного обеспечения (у них, насколько я понимаю, просто не хватает рук).

В любом случае очень советую ознакомиться.

Удачи!

Автоцитата:

"В книжках, которые мне тут все так советуют здесь прочитать, речь идет о современном состоянии COM и ее применений. Я же говорю о происхождении. 5-6 лет назад, читая одну из первых (и до сих пор лучших на мой взгляд) книг о COM я понял, что корни все-таки лежат не в "обеспечении удобства корпоративных разработок", как сейчас все это представляется, а в интерпертируемых языках (хотя IDispatch там появляется в конце книги). И я по прежнему думаю так. К тому, как сейчас используется COM, это отношения не имеет, конечно.

Или вы хотите убедить меня в том, что не IUnknown — основной интерфейс для вызова VB? Если так, то спасибо, но мне это известно ."

1. "тут ... здесь ..." — ну вы меня поняли
2. интерпертируемых — интерпретируемых
3. "для вызова VB" — "для вызова из VB"