Dll-te lejojne pjese te ndryshme te programeve te zevendesohen apo te permiresohen pa pasur nevoje te rikompilojme programin (vetem DLL-ja qe duhet permiresuar apo zevendesuar ndryshohet).

Ashtu siç mund ta vini re nga emri kodi ne DLL(Dynamic Linked Library) ngarkohet ne kujtesen kryesore ne momentin qe nevojitet (lidhet ne menyre dinamike) keshtu qe nuk ze hapesire nese nuk perdoret asnjehere.

Kodi (funksionet) ne nje DLL mund te perdoren ndermjet processeve te ndryshme, çka eshte shume effektive ne lidhje me problemin e zenies se memories (kujteses) ne krahasim me lidhje statike (static Linking)

Megjithese funksionet ne DLL mund te thirren nga gjuhe te ndryshme programimi, gjuhet ne te cilat DLL mund te shkruhen jane te pakta.

DLL-te paraqesin per perdorim nga programet e tjera vetem funksione te thjeshta dhe jo objekte. Programimi me objekte (OOP Object Oriented Programming) ka provuar per tashme 30 vjet te jete nje menyre efektive ne programimin dhe mirembajtjen e programeve te reja. Ne kete pikepamje pamundesia e DLL-ve per te bere te paraqitur objekte tek programet qe e perdorin DLL-ne konsiderohet si disavantazh i DLL-se.

DLL-te ngarkohen ne kujtese me ane te emrit te skedarit (file) qe e permban DLL-ne, kjo nenkupton qe emri i skedarit ku do te ruhet DLL duhet te behet i ditur tek programi qe perdor DLL-ne qe ne kohen e kompilimit. Dhe nese emri i ketij skedari ndryshon apo vendi (direktoria) se ku ruhet ky skedar ndryshon atehere programi i gjore qe kujton se DLL-ja eshte ende aty ku mendon ai deshton te ngarkoje DLL dhe natyrisht deshton te marre ndihmen (therrase funksionet) qe kerkonte nga DLL.

Eshte e veshtire te nxirren versione te reja te DLL-ve ne te njejtin system (komputer) pasi egzsiston nje mundesi e forte per konflikte midis produkteve te shitesve te ndryshem. Juve mund tju kete rene rasti te instaloni ndonje program dhe pastaj diçka tjter te mos ju punoje ne rregull, ajo çka ndodh eshte mbishkruajtja e ndonje DLL-je qe perdoret nga programi qe krijon probleme me vone.

COM eshte nje specifikim(bashkesi rregullash)
Specifikimet ose percaktimet apo bashkesia e rregullave qe COM-i i percakton pershkruajne standarted qe jane te nevojshme te ndiqen ne menyre qe te ndertoni componente COM. Keto standarte pershkruajne se si duhet te duket nje component COM dhe se si duhet te sillet (çfare reagimesh duhet te jape ne varesi te ngjarjeve te ndryshme qe ndodhin gjate kontaktit te tij me programe te tjera ne kohen e egzekutimit te tij)

COM eshte nje bashkesi sherbimesh
Bashkesia e rregullave (specifikimi) qe COM-i paraqet eshte i mbeshtetur nga nje bashkesi sherbimesh apo API-s(Application Program Interfaces). Keto sherbime jane te permbajtura ne librarine e COM-it, e cila eshte pjese e systemit operativ ne platformat Win32, dhe i vlefshem si pakete e veçante per systemet e tjera operative.

COM-i lejon krijimin e programeve modulare
Komponentet e COM-it mund te paketohen si DLL apo ne EXE *(procese te egzekutueshme) dhe COM siguron mekanizmin e komunikimit per te lejuar komponentet ne module te ndryshme per te komunikuar me njeri tjetrin. (Modul eshte nje term logik qe ne e perdorim per tju referuar hapesires qe i ofrohet nje aplikacioni te veçante, hapesire kjo qe nuk mund te preket nga ndonje aplikacion tjeter, si rrjedhoje nje mekanizem komunikimi midis komponenteve ne module te ndryshme eshte i nevojshem.)

* Ne COM+ te gjithe komponentet paketohen ne DLL .

COM eshte i orientuar me objekte (Objek-Oriented).
Komponented e COM-it jane objekte sipas kuptimit te zakonshem qe ne kemi per objektet: kane karakteristika, dhe sjellje dhe ne disa rrethana te veçanta objektet e COM-it mund te trajtohen menyre shume-formshe (poly-morfike). (Lexuesi duhet te jete familiar me terma lidhur me programimin me objekte)

COM lehteson ndryshimin dhe permiresimet(krijimet e versioneve te ndryshme) te programeve tuaja
Komponentet e COM-it lidhen ne menyre dinamike, dhe COM perkufizon menyra standarte (Vini re: se si ne ne nje fare menyre i referohemi specifikimit qe COM ofron) per te percaktuar vendndodhjen edhe identifikimin (njohjen) e funksionalitetit (veprimeve) te tyre, keshtu qe komponentet nje nga nje mund te zevendesohen me te rinj pa pasur nevoje per te kompiluar programin e tere.

COM ofron mundesine e ndarjes se detyrave te programit ne rrjet (network).
COM-i siguron mekanizmin e komunikimit te komponenteve per te bashkevepruar npemjet network-ut. Ajo çka eshte me e rendesishme COM mundeson shkruajtjen e programeve pa u shqetesuar per vendndodhjen e perberesve(komponenteve)te tij. Perberesit (komponentet) e programit mund te levizen pa kerkuar ndonje ndryshim te programit qe i perdor keto perberes (komponente).

Komponentet ne COM-it mund te shkruhen ne shume gjuhe te ndryshme programimi
COM eshte nje standart binar. Çdo gjuhe qe mund ta perballoje kete standart binar mund te krijoje apo perdore komponentet e ndertuar ne COM. Numri i gjuheve dhe mjeteve te ndryshme ndihmese qe mbeshtesin COM-in eshte i konsiderueshem. C,C++,Java,JScript,Visual Basic,VBScript,Delphi,PowerBuilder dhe MicroFocus COBOL perbejne vetem nje pjese te listes.

Binary Large OBjects (BLOB) (Objektet e Medha Binare)

Meqenese ne literaturen e huaj ndoshta do te ndeshni termin BLOB ne nuk po e ndryshojme ne shqip OMB(Objektet e medha Binare) Ne fund te fundit BLOB mund te shqiptohet me kollaj.

BLOBs nuk jane gje tjeter veçse nje sekuence numrash binare te ruajtura ne memorie. Ne kete menyre çdo e dhene, grafike apo program mund te shikohet si nje BLOB.

Nese nje BLOB (qe s'eshte gje tjeter veçse nje bllok adresash memorie i mbushur me 0 dhe 1-sha) ndjek rregullat qe percakton COM-i atehere me plot goje do te quhet nje COM Objekt. Por cilat jane keto rregulla.

Ne figuren me poshte eshte parqitur nje BLOB.Pjesa e nxire tregon hapesiren qe ze ky BLOB. FPRIVATE "TYPE=PICT;ALT=Nje BLOB i pakuptueshem"

Problemi qe del eshte se ne nuk dime si ta interpretojme permbatjen e ketij BLOB-i Nje pergjigje do te ishte te kercenim ne adresen e pare te BLOB-it dhe te fillojme egzekutimin. Kjo eshte nje marreveshje qe shpesh perdoret ne systemet e operimit per egzekutimin e programeve dhe eshte ne fakt menyra se si DLL (Dynamic Linked Libraries) punojne. Specifikimi apo thene ndryshe rregullat e COM-it perbehet nga nje bashkesi marreveshjesh shume te ngjashme me kete ilustrim.

Problemi ne Boten e vertete eshte shpesh me i komplikuar. Shumica e BLOB-eve jane me te komplikuara dhe ofrojne shume funksione apo sherbime per programe te tjera. Si rrjedhoje eshte shume e nevojshme per nje program qe do te perdore nje BLOB te kuptoje se çfare funksionesh ofron BLOB-i dhe te gjeje nje menyre se si ti perdore keto funksione.

Nje menyre per te arritur kete eshte te shenojme nje adrese memorie brenda BLOB-it qe eshte thjesht nje pointer tek nje funksion (pjese e BLOB-it) dhe programi thirres mund te therrase kete funksion per te marre vesh se çfare funksionesh te tjera BLOB-i ofron. P.sh nga ky funksion programi qe therret BLOB-in mund te marre adresat e funksioneve te tjera ne BLOB dhe pastaj mund ti therrase kur te deshiroje.

Ne figuren me poshte vendi memories shenuar me kryq eshte fillimi i nje funksioni qe programi thirres mund te therrase per te marre informacion mbi funksionet e tjera qe BLOB-i ofron. Se si implementohet (ndertohet) ky funksion do te tregojme me poshte ne kete faqe.

Tani çdo program qe do te perdori BLOB-in kur do te marre vesh se çfare ofron BLOB kercen ne kete adrese qe ne me marreveshje mund te vendosim qe te jete ne adresen e dyte te BLOB-it.

Pas kesaj çdo program mund te perdore te gjitha avantazhet qe ofrohen nga çdo BLOB qe e zbaton marreveshjen e bere. Kjo marreveshje punon bukur dhe eshte e mjaftueshme per sisteme operimi si p.sh. DOS ku ka vetem nje program qe egzekutohet ne nje moment te caktuar. Kur programi mbaron se egzekutuari edhe BLOB-i ndalon dhe shkarkohet nga memoria.

Ne systeme operative multi-tasking siç eshte p.sh Windows nuk eshte e jashtezakonshme qe nje BLOB te perdoret nga me shume se nje program ne te njejten kohe. Çdo klient (program qe perdor BLOB-in) mund ti kerkoje BLOB-it qe te te perdore sherbime te ndryshme nen emrin e tij. Me qellim qe BLOB-i te bashkeveproje si duhet me keta kliente duhet qe BLOB-i te ruaje nje gjendje te caktuar per secilin nga klientet. Qe te realizohet kjo duhet qe ne njefare menyre secili klient ti tregoje BLOB-it se do te perdore sherbimet e tij dhe te lajmeroje kur mbaron me BLOB-in dhe nuk ka nevoje me per te.

Ne figuren e meposhtme paraqitet nje pamje BLOB-it tani i pajisur me dy pozicione te reja

Me marreveshje do vendosim qe vendi ne memorie i shenuar me rreth do te jete fillimi i nje funksioni qe klientet mund te therrasin per ti treguar BLOB-it se po e perdorin ate ndersa vendi tjeter do shenjoje tek nje funksion tjeter qe klientet mund te therrasin per ti treguar BLOB-it se kane mbaruar se perdoruri BLOB-in. (Edhe ketu per momentin nuk po zgjatemi ne menyren se si keta funksione do te implementoheshin ne BLOB, kjo do te jepet me poshte ne faqe. Ju do te shikoni edhe vete qe keto funksione jane shume te thjeshta).

Meqenese tek BLOB-i eshte e rendesishme qe te percaktohen me marreveshje tre funksione themelore atehere do te ishte me mire sikur pointerat (shenjuesit) e ketyre tre funksioneve ti ruanim ne vende te njepasnjeshme. Duke vepruar keshtu ne percaktojme vetem nje pointer (shenjues) (ate ne fillim te tabeles) dhe pastaj kur kemi nevoje per ndonjerin nga funksionet mund ta gjejme kollaj shenjuesin(pointerin) e tij relativisht me kete pointer.

Ne figuren e meposhtme paraqitet nje ilustrim e nje BLOB-i te pershkrimit qe sapo dhame me siper.

Vini re se ne figure perveç tre shenjuesve tek funksionet themelore ne rradhe eshte edhe nje pointer tek nje funksion tjeter qe BLOB-i ofron. Ne fakt BLOB-i mund te ofroje edhe me shume se nje funksion te tille.

Interface ne shqip ne do ta perkthenim Paraqitje, Pamje, Prezantim apo Nderfaqe cila t'ju duket me mire. Prape per arsye se ju mund te gjeni kete term ne shume libra e ne internet, ne do te vazhdojme te perdorim termin Interface.

Shenjuesi fillestar i tabeles qe permban shenjuesit e funksioneve quhet Interface. Ne figuren e paragrafit me siper kjo tabele eshte pjesa e vendeve me te nxira. Sa per ti ngaterruar pak punet nje interface referohet nepermjet nje pointeri tek nje pointer.

Shpesh tabela e funksioneve qe nje Interface paraqet quhet vtable (ju mund ta keni degjuar termin vtable si emer per tabelen e funksioneve virtuale te nje klase ne C++. Me vone ne kete faqe do te shohim se si tabela e funksioneve virtuale, vtable, mund te perdoret per te ndertuar nje interface).

Shenim: Ne jeten e perditshme ne gjuhen Angleze, Interface quhet pamja e jashtme qe nje objekt paraqet per te komunikuar me te, p.sh nje video paraqet nje grup butonash me ane te cileve ne mund ti kerkojme videos te kryeje ndonje nga funksionet e ndryshme qe video-ja ofron. Ky grup butonash perben ate qe quhet Interface i videos.

Nje BLOB mund te paraqese me shume se nje Interface.

Nje program komunikon me BLOB nepermjet Interface-eve qe ky paraqet. Logjikisht nje interface mund te mendohet si pamja fizike qe nje objekt paraqet per te komunikuar me nje objekt apo program tjeter.

Me siper ne percaktuam tre funksione themelore qe nje BLOB duhej te kishte per te mundesuar komunikimin themelor me programe apo objekte te tjera nga jashte.

Modeli COM specifikon qe cdo interface duhet patjeter ti kete keto tre funksione ne tre vendet e para ne vtable (tabela e shenjuesve te funksioneve).

Tre funksionet themelore qe nje Interface ne nje COM objekt duhet te perfshije patjeter quhen perkatesisht QueryInterface, AddRef, Release.

Te tre keto funksione te vendosur ne nje tabele te vecante formojne nje nje Interface qe quhet IUknown interface.

BLOB-i i mesiperm implementon vetem nje Interface qe ne e kemi quajtur INjeInterfaceCOMi.

"Nje BLOB quhet COM object nese çdo interface qe ai paraqet perfshin edhe tre funksionet themelore te IUnknow Interface."

Pra çdo interface qe nje COM objekt paraqet duhet te perfshije dhe IUnknown Interface, me nje fjale duhet qe tre pointera te pare ne tabelen e funksioneve te jene ato te interface-it IUnknown.

Figura me poshte paraqet te njejtin COM objekt qe eshte paraqitur ne figuren pak me siper. Ne figuren me poshte eshte per qartesi eshte ndare pjesa e memories qe permban Interface-in dhe ajo qe permban implementimin e kesaj Interface. (Vini re ne vtable e kesaj Interface tre funksionet e para jane ato te IUnknown).

Ne figuren me siper me shenjen "&" nenkuptojme "adressa e".

Trupet e funksioneve (kodi qe kryen punen) do te jene pjese e komponentit d.m.th do te perfshihen ne BLOB (kujtoni qe BLOBi eshte sekuence binare shih figuren paraardhese). Rradha e implemetimit te funksioneve nuk ka rendesi ne BLOB pasi keto do te referohen vetem nepermjet tabeles se funksioneve ne Interface. P.sh ne figuren mesiper tregohet se trupi i FunksionD() eshte i vendosur ne adresat e memories perpara FunksionB() dhe FunksionC(). Fare mire mund te ishte vendosur edhe perpara implementimit te cdo funksioni tjeter ne Interface. COM (Component Object Model) nuk specifikon ndonje rregull mbi rradhen e vendosjes se implementimeve te funksioneve. Nese ju implementoni funksionet e paraqitura nga Interface-i dhe i incializoni adresat e funksioneve ne vtable ashtu siç duhet, me COM-in jeni ne rregull.

COM (Component Object Model) specifikon (vendos si rregull standart) qe pasi nje Interface eshte publikuar nuk duhet te ndryshoje me. Nuk duhet as te shtoje as te heqe funksione ne tabelen e funksioneve qe ajo paraqet. Me publikim te Interface-it ketu nenkuptojme nxerrjen ne perdorim te objekteve qe e ofrojne ate Interface, d.m.th pasi te keni shitur apo dhene per perdorim programuesve te ndryshem qe perdorin komponentet tuaj qe ofrojne Interface-in. Arsyeja qe COM-i e vendos kete specifikim eshte per te menjanuar gabimet qe mund te shkaktohen.

P.sh Imagino se keni ndertuar nje COM objekt Nxenes qe nder te tjera ofron nje Interface te quajtur IJeto. (Shpesh programuesit vendosin shkronjen "i" te madhe te shtypit perpara emrit te Interface-it. Ide e mire per te treguar se po behet fjale per nje Interface.) Ta zeme se ne fillim interface ofronte funksionet, Meso(), Argetohu(), Ha(), Pi(), Rri(), Qaj(), Buzeqesh() . Nese ju keni publikuar objektin tuaj atehere supozohet se komponenti juaj eshte vene ne perdorim ne programe te ndryshme.

Tani nese ju ndryshoni Interface-in dhe i hiqni nje metode. P.sh nese hiqni metoden Meso(). Kur te instaloni objektin mbi nje version e meparshem, programet qe i referohen objektit nepermjet Interface-it IJeto nuk do te kene dijeni fare per ndryshimet qe i kane ndodhur Interface-it. Nese ndonjeri nga programet ka thirrur proceduren Meso() diku atehere programi do te shkaktoje access violation, sepse do te perpiqet te therrase adresen e nje funksioni qe nuk egziston.

Mire per te hequr metoda u krijoka gabim tek programet qe paskan filluar te perdorin komponentin nepermjet Interface-it, per te shtuar nuk ka pse te krijohet problem. Keshtu duket ne pamje te pare.

Ta zeme se ju keni shtuar nje funksion tjeter ne interface-in IJeto dhe ky funksion quhet Dashuro(). Tani ju ecni me mendimin se gjithshka eshte ne rregull. Programet e vjetra nuk dine gje per kete funksion dhe thjesht nuk e therrasin. Programet e reja qe ndertohen e dine se ky funksion egziston dhe do ta therrasin.

Prit pak! ... Po sikur nje program i ri qe perdor funksionin Dashuro() te instalohet ne nje kompjuter qe permban COM objektin me Interface IJeto qe nuk e ka funksionin Dashuro(). Programi krijon nje objekt te tipit Nxenes dhe kerkon per Interface-in IJeto dhe e gjen kete Interface. Programi i ri nuk ka asjne menyre si ta kuptoje nese Interface-i IJeto ka funksionin Dashuro() apo jo. Ky i shkreti kujton se Nxenesi mund te dashuroje dhe i therret funksionin duke shkaktuar nje access violation. "Kot nuk thone dashuria te verbon". Ne rastin me te mire Sistemi operativ e dallon kete access violation dhe detyrohet te pushoje egzekutimin e programit ne vend.

Shkurt muhabeti ata te microsoftit e kane ditur se cfare po flasin kur kane vendosur qe te ofrojne si rregull standart te COM (Component Object Model) qe pasi te ndertohet nje interface nuk duhet as ti shtohen as ti hiqen funksione.

Pasi Interface-i juaj eshte vene ne perdorim nga kliente te ndryshem mos e ndryshoni me. Kur publikoni nje interface mendoni sikur keni firmosur nje kontrate me perdoruesit e interface-it tuaj qe thote "Betohem se nuk do ti ndryshoj funksionet qe kjo Interface paraqet"

Fakti qe tabela e funksioneve qe ofrohen nga nje Interface nuk duhet te ndryshoje nuk do te thote qe implementimi (trupi) i funksioneve te mos ndryshoje.

Ne fakt eshte shume raste per arsye te ndryshme per nje Interface programuesit ofrojne implementime te ndryshme. P.sh nje implemetim i Interface-it eshte per te ju pershtatur Windows NT nje tjeter per Unix e nje tjeter per Windows98, 2000 e nje tjeter per Apple Macintosh. Keshtu qe kur komponenti instalohet ne computer qe punon ne Windows NT implemetimi i ndertuar veçanerisht per Windows NT do te perdoret.

Termi Inheritance nuk eshte i ri nese jeni me eksperience ne C++ apo gjuhe te tjera te orientuara me objekte. Inheritance perkthehet ne shqip Trashegimi (keshtu eshte ne fjalor). Inheritance ketu perdoret me shume ne kuptimin qe femija trashegon cilesite e prinderve (p.sh ngjyren e syve, sjelljen e tjer) dhe jo pasurine e tyre :).

Ju duhet te jeni te ambientuar termin Klase dhe me Inheritancen (trashegimine) e klasave ne C++. Kur thuhet se nje Klase A trashegon nje tjeter Klase B nenkuptohet se klasa A i ka te gjitha karakteristikat e metodat qe ka klasa B plus mund te shtoje edhe ndonje karakteristike dhe/ose metode tjeter.

Inheritanca e klasave ne C++ nganjehere quhet implementation inheritance, çka nenkupton se kur nje klase trashegon nje tjeter atehere se bashku karakteristikat e asaj klase trashegohet edhe trupi (kodi) i funksioneve.

Inheritanca e Interface-ve nuk eshte patjeter implementation inheritance d.m.th nuk do te thote patjeter qe edhe trupi i funksioneve te trashegohet.

"Thuhet se nje interface inherits IA (trashegon) nje tjeter IB nese IA perfshin ne fillim te tabeles te gjithe funksionet qe IB permban ne vtable e saj."

Shikoni figuren me poshte. IBaze eshte nje interface dhe IeDerivuar eshte nje interface tjeter qe inheriton nga IBaze.

Meqenese IeDerivuar inheriton nga IBaze atehere patjeter kjo interface duhet te kete ne fillim te vtable te saj te gjitha funksionet qe IBaze paraqet.

Inheritanca e interfaceve nuk thote asgje per implementimin e funksioneve. Figura mesiper tregon qe IeDerivuar implementon dy funksionet e para njelloj si IBaze (pointerat e funksioneve shenjojne te njejtat adresa). Megjithate IeDerivuar ka vendosur te implementoje Funksion3() nepermjet nje funksioni tjeter. Per me teper ky funksion ka edhe emer tjeter (TjeterFunksion3() ).

COM nuk do tia dije se cfare emri ka funksioni kur implemetohet. Te gjithe implementimet e funksioneve do te do te referohen nepermjet adreses se ruajtur ne vtable.

Nje COM objekt mund te paraqese me shume se nje Interface. Si psh ne figuren me poshte.

Figura e mesiperme paraqet nje COM objekt qe quhet Personalitet me dy Interface. IDoktor dhe IPolitikan.

COM specifikon qe e vetmja menyre per te komunikuar me nje COM objekt eshte nepermjet interfaceve qe ai paraqet. Nuk ka ndonje pointer te veçante per tiu referuar te gjithe objektit.

Kur nje program ka nevoje per nje COM objekt atehere ai krijon COM objektin dhe merr nje shenjues mbi njeren nga Interface-et qe COM objekti ofron. Programi mund te specifikoje se cilen Interface deshiron marre.

P.sh nese nje program do te kishte nevoje te perdorte funksionet e Interface-it IDoctor ne COM objektin e paraqitur ne figuren e mesiperme, hapat qe do te ndiqte do te ishin.

Po sikur programi te deshiroje te perdore edhe interface-in IPolitikan te objektit te krijuar ? Natyrisht qe programi mund te krijonte nje objekt tjeter dhe te merrte nje shenjues mbi IPolitikan. Por ky do te ishte plotesisht nje objekt tjeter (komplet personalitet tjeter :) ).

Pergjigjja eshte tek funksioni QueryInterface(). Me siper kur u fol per BLOB-et eshte shkruar qe "QueryInterface() mund te perdoret per te kuptuar se çfare funksionesh ofron nje COM objekt" , kjo eshte e pasakte.

Saktesisht "QueryInterface() perdoret per ti kerkuar COM objektit te ktheje nje pointer mbi nje interface te veçante."

"Query" do te thote "pyet". QueryInterface qendron per "PyetPerInterface".

Nese nje program deshiron te perdore te dy interfacet e COM objektit te me siperm atehere hapat qe do te ndiqte jane:

Me vone do te flasim me shume per QueryInterface().