Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ?
01.11.04 15:10: Перенесено модератором из 'Прочее' — _MarlboroMan_
15.11.04 20:36: Перенесено из 'Философия программирования'
Здравствуйте, Аноним, Вы писали:
А> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ?
Microsoft на COM забил, так что можно сказать, что устарел. И, откровенно говоря, слава богу, поскольку более замуженную технологию еще поискать.
Здравствуйте, Аноним, Вы писали:
А> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ?
Бррр...
Как правило, применение СОМ не оправданно и не нужно. В больших ситсемах СОМ пытаются юзать чтобы отделить интерефейс от реализации и чтобы можно было править реализацию отдельных компонентов не ломая и не пересобирая всего остального. В С++ для отделения интерфейса от реализации (и сохранения двоичной совместимости) лучше всего воспользоваться паттерном P-Impl. Это лучше во всех отношениях и не требует введения дополнительного как правило не нужного уровня виртуализации.
Здравствуйте, <Аноним>, Вы писали:
А> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход?
Смотря что в замен. Если монолит на С++, то лучше уж КОМ. А если тоже самое но на Яве или дотнете и без скриптов, то конечно КОМ прошлый век.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
VD>>Если монолит на С++, то лучше уж ... А если тоже самое но на Яве или дотнете и без скриптов... ЗХ>Ну Влааааад!
Чё Влад? Влад этим (КОМ-ом) 7 лет занимался. И забил на него полсе появления дотнета. Дотнет лучий на сегодня вариант компонентного фрэймворка. Компоненты в нем встроены очень гладко.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Смотря что в замен. Если монолит на С++, то лучше уж КОМ. А если тоже самое но на Яве или дотнете и без скриптов, то конечно КОМ прошлый век.
Вы просто их готовить не умеете, монолиты на С++. Разбить на части можно грамотно и на С++ не добавляя лишний уровень виртуализации.
Здравствуйте, Kluev, Вы писали:
K>Вы просто их готовить не умеете, монолиты на С++. Разбить на части можно грамотно и на С++ не добавляя лишний уровень виртуализации.
Не будь стольк категоричным. Я их очень долго и успешно готовил. От того и пришел к компонентному подоходу. МС тоже их ооочень долго готовил и тоже пришел к тому же.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ?
А ты не спрашивал, в каком году начинался проект, и какие сист. требования приходили от клиентов или маркетинга?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>Вы просто их готовить не умеете, монолиты на С++. Разбить на части можно грамотно и на С++ не добавляя лишний уровень виртуализации.
VD>Не будь стольк категоричным. Я их очень долго и успешно готовил. От того и пришел к компонентному подоходу. МС тоже их ооочень долго готовил и тоже пришел к тому же.
Да ничего МС не готовил. Возьми ту же МФЦ, где там успешное приготовление? Так прикрыли помойку вынь апи газеткой, и не более. То же самое и с остальными прогами.
P/S А насчет компонентного подхода, так в своих прогах я от него отказался, а почему? Да потому что компонентность реально требуется только в плагинах, да и то это можно сделать только наполовину компонентным. Т.е. компонентный только плагин. Щас разьясню подробнее.
Допустим есть интерфейс плагина IPlugin. плагинов может быть много поэтому это оправданно. В каждом плагине есть своя реализация IPlugin. Теперь есть интерфейс IApplication который необходим плагинам. Но ежу понятно, что две реализации IApplication быть не может. т.к. прилоджение-то одно, а IApplication фактичеки воодится только для обеспечения двоичной совместимости. Чтобы старые плагины работали с новыми версиями нашей проги. Теперь спрашивается зачем нам IApplication с дополнительным уровенем виртуаллизации и дополнительным гемором? Совсем он нам ни к чему. Вместо этого огорода, делаем так:
class MY_API Aplication
{
struct App_imp *imp_;
public:
int someValue_get();
};
И таким же макаром все остальные классы необходимые плагинам, и выносим все это в ДЛЛ Т.к все данные вынесены в struct App_imp, то лекго обеспечивается двоичная совместимость с будующими версиями. Т.е. старые плагины будут пахать без перекомпиляции.
Таким образом можно поскипать 80% всех лишних интерфейсов и компонентности.
ИМХО вобще тяга к компонентности это своего рода болезнь начинающих, я в начале работы тоже стремился все как следует изолировать, сделать компонентным, а оказалость что от этого пользы ноль. Теперь компонентность живет только там где это действительно необходимо.
P.S.S: И где кстати ты видел у МС проги написанные в таком стиле? У них либо монолит, либо помйка с ОЛЕ. Которая ни себе ни людям. Наружу торчат какие-то полулевые наполовину реализованные интерфейсы возвращающие E_NOTIMPL, а для себя юзаются закрытые.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Аноним, Вы писали:
А>> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ? GZ>А ты не спрашивал, в каком году начинался проект, и какие сист. требования приходили от клиентов или маркетинга?
GZ>С уважением, Gleb.
Боюсь что теперь это уже не имеет для них значения .... И что теперь всем делать делать с этой куой написанного кода на MFC, COM, и т.д. и т.п....
Здравствуйте, Aviator, Вы писали:
A>Здравствуйте, GlebZ, Вы писали:
A>Боюсь что теперь это уже не имеет для них значения .... И что теперь всем делать делать с этой куой написанного кода на MFC, COM, и т.д. и т.п....
Считать деньги, ессесно. Если система правильно написана, то и ведение ее не дороже чем на Net. Если вся эта шняга, начала тянуть огромное кол-во ресурсов (а такое рано или поздно случается), то можно переписать на Net. Но при этом провести маркетинговое исследование — не все пользователи согласны иметь компы по 256-512 мб и в нынешнее время. А если не могут, то переписывать на том же уровне COM+VBScript (кстати, не очень плохой выбор для определенных задач). Бизнес — есть бизнес.
Когда-то и я принимал участие в проекте на COM+VBScript. Жить можно, и местами даже неплохо.
Здравствуйте, <Аноним>, Вы писали:
А> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ?
А что за проект, точнее можно узнать? COM хорош ради того, чтобы обеспечить интерфейс к VB/VBS/etc. И только. Как средство обеспечения компонентности для C++ модулей, ИМХО, избыточен и слишком ограничен для C++.
Насчёт устаревания — нет, не устарел.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
K>>Вы просто их готовить не умеете, монолиты на С++. Разбить на части можно грамотно и на С++ не добавляя лишний уровень виртуализации. VD>Не будь стольк категоричным. Я их очень долго и успешно готовил. От того и пришел к компонентному подоходу. МС тоже их ооочень долго готовил и тоже пришел к тому же.
MS пришла к тому, что неплохо бы Java потеснить.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>МС тоже их ооочень долго готовил и тоже пришел к тому же.
У МС задачи были другими. Они платформы делали. А потому и не могли привязываться ни к какому конкретному языку (или реализации языка). Вот СОМ и придумали. Как вынужденую меру... Ну а логичным продолжением этого, как ты верно подметил, стал дотнет.
Здравствуйте, Kluev, Вы писали:
K>Да ничего МС не готовил. Возьми ту же МФЦ, где там успешное приготовление?
Ты Ворд возьми на С писанный. Эксель плюсовый. Саму виндовс. Все они прошли эволюцию от огромного монолита до компонентных продуктов. А МФЦ — это левая библиотечка котору в МС используют раз в код для написания продуктов вроде Вордпэда.
K> Так прикрыли помойку вынь апи газеткой, и не более. То же самое и с остальными прогами.
И тем не менее ты в жизни не создашь продуктов с таким же объемом исходного кода.
K>P/S А насчет компонентного подхода, так в своих прогах я от него отказался, а почему?
Потому что у тебя нет команды из сотни разработчиков.
K> Да потому что компонентность реально требуется только в плагинах, да и то это можно сделать только наполовину компонентным. Т.е. компонентный только плагин. Щас разьясню подробнее.
Это потому что вы не умете ее готовить.
K>ИМХО вобще тяга к компонентности это своего рода болезнь начинающих, я в начале работы тоже стремился все как следует изолировать, сделать компонентным, а оказалость что от этого пользы ноль.
Ну, значит ты матерый проффесионал, а я, ребята из МС, Сана, IBM-а, Apple-а и т.п. начинающие или вовсе ламеры.
Конечно не чето не должно переростать в навязчивую идею. Компонентный подход нужнен безусловно только там где нужен. Причем нужно очено хорошо уметь выделять те места где он нужен. Однако у тебя я вижу обратную болезнь — борьбу с КОП.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>У МС задачи были другими. Они платформы делали.
МС делает (сейчас) сотни продуктов. От игр для ХБокса, до Ворда с Экселем. И везде компонетный подход применяется на всю катушку. И это именно от того что МС большая команию в которой понимают что можно выжать из этого подхода.
V> А потому и не могли привязываться ни к какому конкретному языку (или реализации языка).
У них 70% кода на С написано. Еще 25% на С++. Сейчас вот на Шарпе пытаются переписывать. Так что проблем с языком у них никогда не было.
V> Вот СОМ и придумали. Как вынужденую меру... Ну а логичным продолжением этого, как ты верно подметил, стал дотнет.
Дык придумали именно потому что по другому уже нельзя было.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>У них 70% кода на С написано. Еще 25% на С++. Сейчас вот на Шарпе пытаются переписывать. Так что проблем с языком у них никогда не было.
Да, но заметь, что и с офисом, и с эксплорером и с другими пакетами можно свободно работать используя делфи, VB6, теперь вот .NET, либо ЛЮБОЙ ДРУГОЙ язык, который понимает бинарный стандарт СОМ. То есть, когда МС разрабатывала эти продукты, она расчитывала на использование их из вне. Как ты думаешь, возможно бы это было, если бы экспорт классов шел напрямую из С++? То-то же!
VD>Дык придумали именно потому что по другому уже нельзя было.
Совершенно верно! Если бы виндовс была операционной системой ОДНОГО ЯЗЫКА (С++), то никакой СОМ нафиг бы не был нужен!!! Но, это не так, а потому СОМ действительно был вынужденной мерой.
Здравствуйте, VladD2, Вы писали:
ГВ>>MS пришла к тому, что неплохо бы Java потеснить. VD>А Ява думешь что такое? У нее компонентный подход в сердцевине идеологии. Каждый класс — компенент.
Угумс, потому и подрались
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
.... И что теперь всем делать делать с этой куой написанного кода на MFC, COM, и т.д. и т.п....
