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

S>Прошу заренее извинить за то, что не пишу русским фонтом. Я постараюсь это устранить как можно быстрее.
Proshu zaranee izvenit' za to chto ne pishu russkim fontom. Ia postaraus' eto ustranit' kak mojno bistree.

S>Уже давно у меня была идея написать "улучшенный СОМ". Для своих проектов я использую свои библиотеку, которая своеобразный менеджер компонентов.

Это твоё неотъемлемое право. Как такое же как у меня при разработке моих улучшений для меня.

S>СОМ это далеко не единственный потенциальный план(конструкция?дизайн? design), который может решить поставленные им (СОМ-ом?дизайном?) проблем. Хочу услышать мнения по поводу моих идей, которые я привожу ниже.

S>Мне кажется, самая главная ошибка, которую допустили разработчики СОМ состоит в том, что для клиента нет разницы между компонентом и интерфейсом.

Действительно ли нет? Что он создаёт и чем пользуется?
Ты скажешь: "клиент создаёт интерфейс и пользуется им" или "клиент создаёт компонет и пользуется им" (если бы не было разницы!) — и оказывается, что построить-то на этом базисе что-то стОящее (или работающее) и нельзя.

S>Чтобы объяснить мою точку зрения, я приведу пример С++ кода:

S>class IClass1 {...};
S>class IClass2 {...};
S>class CMyClass : public IClass1, public IClass2
S>{
S>    ...
S>};

S>// рассмотрите следующий отрывок:
S>CMyClass class;
S>IClass1 i1 = (IClass1)class;
S>IClass2 i2 = (IClass2)i1;         // самый важный момент

S>Посмотрите на последнюю строку кода. Мы пытаемся получить один интерфейс из другого, абсолютно не имеющего ни какого отношения к первому. Естественно это не имеет смысла. А ведь именно это является основным требованием СОМа. Все интерфейсы компонента должны знать обо всех других интерфейсах. Это абсолютно не интуитивно для клиента и предоставляет основную проблему в написании объекта для сервера. Не лучше ли при вызове CoCreateInstance получать указатель к компоненту, из которого можно было бы вызывать QueryInterface()? Это бы значительно облегчило работу с СОМ-ом, написание и использование объектов и т.д.

А тут и нет никаких проблем, как для клиента, так и для сервера.
Есть проблемы взгляда на мир компонентов глазами С++ программиста и ужаса при мысли, что, оказывется!, не все компоненты представимы в виде С++ классов. Вот ужас-то!
Но СОМ — это вовсе не "С++ Object Model".

S>Конечно приведённый вверху код работает при использовании указателей и dynamic_cast<>. Но это вряд ли является правильной постройкой плана(конструкции?дизайна? design), абсолютно не интуитивно и не должно быть использовано в хорошем коде/разработке(конструкции?дизайне? design). Что интересно, ни в одной книге/статье про СОМ не указывается, что его план(конструкции?дизайна? design) мог бы быть другим, и никогда не приводится примеров, каким он мог быть и почему настоящий план(конструкции?дизайна? design) является лучше этого примера.