Proshu zaranee izvenit' za to chto ne pishu russkim fontom. Ia postaraus' eto ustranit' kak mojno bistree.

Uje davno u meania bila idea napisat' "uludshennii COM". Dlia svoih proektov ia ispol'zuu svou bibleoteku kotoraia svoeobraznii manager komponentov. COM eto daleko ne edinstvinnii potencial'nii design kotorii mojet reshit' postavlennie im problem. Hochu uslishat' mneniia po povodu moih idei kotorie ia privoju nije.

Mne kajetsia samaia glavnaia oshibka kotoruu dopustili designeri COM sostoit v tom chto dlia klienta net razneci mejdu komponentom i interfasom. Chtobi ob'iasnit' mou tochku zreniia, ia prevedu premer C++ koda:

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

// rassmotrite sleduuschii otrivok:
CMyClass class;
IClass1 i1 = (IClass1)class;
IClass2 i2 = (IClass2)i1;         // samii vajnii moment

Posmotrite na poslednuu stroku koda. Mi pitaemsia poluchit' odin interface iz drugovo, obsolutno ne imeuschego ni kakogo otnoshenia k pervomu. Estestvenno eto ne imeet smisla. A ved' imenno eto iavliaetsia osnovnim trebovaniem COMa. Vse interfasi kompanenta doljni znat' obo vseh drugih interfasah. Eto absolutno ne intuitivno dlia klienta i predstovliaet osnovnuu problemu v napisanii ob'ekta dlia servera. Ne ludshe li pri vizove CoCreateInstance poluchit' ukazatel' k kompanentu iz kotorogo mojno bilo bi vizivat' QueryInterface()? Eto bi znachitel'no oblehchilo rabotu s COMom, napisanie i ispol'zovanie ob'ektov, i t.d.

Konechno prevedennii vverhu kod rabotaet pri ispol'zovanii pointerov i dynamic_cast<>. No eto vriadli iavliaetsia pravil'noi postroikoi designa, absolutno ne intuitivno i ne doljno bit' ispol'zovano v horoshem kode/designe. Chto interestno, ni v odnoi knige/stat'e pro COM ne ukazivaetsia chto ego design mog bi bit' drugim, i nikogda ne privoditsia primerov kakim on mog bit' i pochemu nastoiaschii design COM iavliatsia ludshe etogo primera.

Здравствуйте 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) является лучше этого примера.