Така че, решение, което не е достатъчно нашия сървър обект, за да го обикновено може да се справи клиент - намерен. Имаше някои части на проектните решения в точното софтуерен дизайн. Ние открихме, че посочените по-горе видове устройства се нуждаят от указатели към интерфейси, както и справка устройство брой на обекта с вграден "самостоятелно убиец." Те могат да бъдат достъпни само чрез методите на клиент на обекта, което причинява на клиента и същите тези методи трябва или да бъдат част от всеки интерфейс изпълнява от този въпрос, или - специална функция, отделен интерфейс. И всеки един обект, без значение какво семейство и племе той може да бъде - е длъжна да прилага тази функция.
Тъй като изложбата тези функции могат да бъдат само като интерфейс, и предмет на дискусия: какво е по-добре - да ги издава под формата на единен интерфейс, задължението да разкрие, че си да търси някакъв предмет (включително всички други обекти, интерфейси), или - за да добавите тази функционалност към всеки интерфейс, изложени обект ?
Ние определяме това, което казваме. Първият метод ще се нарича QueryInterface- тя трябва prinimatIID друг интерфейс за показване на данни за обекта, и да се върне указател към този интерфейс. Вторият метод го nazyvatsyaAddRef- ще не е включена лампа и всеки носи своя предизвикателство за развитието на референтния брой на обекта напред по един. Третият метод -освобождаване. Неговата задача - obratnayaAddRef, а когато референтния брой достига nulyaReleasezhe причина idelete това.
Защо, вместо метод за управляване на референтния брой, стигнахме до две? Не на последно място, защото този метод повикване код без параметри - по-кратък. Нека няколко байта, но това са няколко байта в клиент се срещат навсякъде, където се размножава индекс. И общо попълнение кодът може да е голям.
Така че, тези три метода:
ние можем да организираме в един интерфейс. Или - ние можем да Ви предпише по част от всеки друг интерфейс. Кое е по-добре? И защо?
Да кажем, че тази функция е получен в напълно отделна интерфейс X. и всички други интерфейси на един и същ обект не разполага. Какво се случва? И това е, което се случва - ако на създаването на обекта, ние ще поискаме сървъра, за да се върне указател към нас interfeysX. е във владение на индекса, ние можем лесно да получите насоки и всички други интерфейси обект -QueryInterfacezhe се състои interfeysaX. Но, ако се поиска от сървъра, за да се върнат всеки друг интерфейс на един и същ обект, така че с този интерфейс и ще остане - това е интерфейс netQueryInterface на. Това принуждава всеки път, когато ние питаме за желания интерфейс и imennoX. и след това от него имат право да ни направи показалка. Има двойно работа от страна на клиента - подготовката на показалеца на интерфейс.
Ако тази функция е поставен във всеки интерфейс, който излага на обект, всеки интерфейс ще бъдат ангажирани в три допълнителна клетка Vtbl. но ние не трябва да направите всяко двойно работа от страна на клиента, всички управлението на съоръжението може да се извършва от всеки от интерфейса му. И изглежда, че вторият метод е много по-удобно за клиента, разбира се - да се използва повторно име сървъра.
Но тъй като ние можем да се изгради такова съоръжение, в който няма да има "полезни" интерфейс? Възможна. Но тази програма функционалност във всеки случай трябва да бъде. И вие може да се размножава показалеца, а след това - за да унищожи обекта. И всички, които над - определя единствено да бъде решен чрез софтуерен проблем.
Описаната функция е толкова фундаментална, че без него ", нищо не работи" - ние направихме и да разсъждаваме върху него, защото в нашето изпълнение на компонент взаимодействие липсваше много значителни фрагменти. Възможно ли е да го изпълни, така или иначе? По-конкретно - да, всъщност - не. В крайна сметка, причината за това, че тази функция като част от обекта - философски. Ако знаехме точното компилатор статично вида на обекта и напишете това е един за клиента и сървъра, разбира се, компилаторът може да се реализира и коригиране на призива за ново и правилно vyzovdelete * и компилаторът ще конвертирате указатели към тип. Но, в действителност, това означава, че както на клиента и сървъра трябва да се постави в контекста на един и същ проект - и ние просто трябва точно обратното "начални условия". Ние и на клиента и сървъра, трябва да се намират в различни проекти в различни контексти. Имаме - програмиране на двоични компоненти.
Това е от гледна точка на това, за първи път взеха участие маси по време на компилацията, вграден в самия обект, така че те да се поддържат и по време на изпълнение (vtbl), и сега трябва да се зареди един обект и функции, като например управление на времето и живота гласове. И ние не можем да го избегнем - или ние самите, или компилатор.
Следва да се отбележи, особено - че въпреки че ние сме изучаване COM. че вече е формулиран философски характер. И тогава, в една или друга форма той може да се намери в realizatsiiCORBA трябва да бъде цяло във всеки двоичен-компонент технология. "Обвивка", която може да е различна, но същността - едни и същи.
В COM, това е наистина фундаментална същност, наречена "interfeysIUnknown", която в свободен превод може да звучи като "неизвестен интерфейс" и е най-малко известна степен озадачен - какво е неизвестен интерфейс, ако е гарантирано от присъствието на всеки обект? Въпреки това, ако се превежда като "интерфейс, не знам кой е" - всичко си идва на мястото. Освен това, двоичен компонент обект ще obektomCOM единствено и само ако тя осъзнава, поне interfeysIUnknown. Ако такъв интерфейс не е - това не е obektCOM. въпреки че, както видяхме, обектът може да бъде "двоичен-компонент" и без ispolzovaniyaCOM.
С този интерфейс, ние волю-неволю ще трябва да отговарят на много близо - той е "алфата и омегата" на всички интерфейси я определя специален поведение на обекта. И сега, докато ние се отбележи, че - всяко COM интерфейс трябва да бъде наследен от interfeysaIUnknown. Трябва да се разбере защо - imennoIUnknownv част от всяка интерфейс управлява живота си обект и актьорския състав на тип указател. И това не се нуждае от допълнителни разходи за клиента.
Всъщност, само въвеждането на обектите на предишния ни пример изпълнение IUnknowni разделени нашите съоръжения да се превърне в "реално obektyCOM". Но, за да се придвижи напред ние трябва да отговарят точно на спецификациите - това е "interfeysCOM" в C ++ и как тя е описана.
Тази ситуация по принцип не може да се "контролира автоматично." Това може да се избегне само точност на всички кодиране, която е изложена на външната страна на модула. Трябва винаги да се помни, че "нормално външно име" C ++ - украсени, т.е. двоичен модул изглежда доста по-различно, тъй като тя се появява в оригиналния текст. Трябва да се помни, че всеки, извън изложени метода трябва да бъдат написани само със съгласието svyazyah__stdcall. Трябва да се помни, че методите, изложени интерфейси не могат да бъдат претоварени. Тези ограничения трябва да бъдат само защото "други компилатори, които не знаят как", Acom - двоичен технология.
Ето защо, на точното познаване на "какъв език се изгради интерфейс към COM" за програмист - жизнена необходимост. Във всеки yazykeC ++ интерфейс описва структурата - структурата на класа, чиито членове yavlyayutsyapublic. Възможно е и описание на интерфейса се konstruktsieyclass. Включване на файлове
#define STDMETHODCALLTYPE __stdcall
#define интерфейс структура
# определят STDMETHOD (метод) метод виртуална HRESULT STDMETHODCALLTYPE
# определят STDMETHOD_ (вид, метод) метод виртуална тип STDMETHODCALLTYPE
# определят DECLARE_INTERFACE (iface) интерфейс iface
# определят DECLARE_INTERFACE_ (iface, baseiface) интерфейс iface. обществен baseiface
и файл
typedef LONG HRESULT;
В един и същи файл
Свързани статии