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.