| Systémový objektový model (SOMOobjects) | |
|---|---|
| Vývojář | CILabs ( IBM , Apple Computer atd.) |
| Operační systém | MacOS , OS /2 , AIX , Windows , DOS |
| Nejnovější verze | 3.0 (prosinec 1996 ) |
System Object Model ( SOM ) je systém objektově orientovaných dynamických knihoven vyvinutý společností CILabs ( IBM , Apple , OMG, Adobe , Oracle atd.). DSOM, distribuovaná verze SOM založená na CORBA , která umožňuje distribuci objektů napříč různými výpočetními systémy. Existují implementace pro operační systémy Windows NT, MacOS Classic, OS/2, AIX, DOS, Copland, OS/390, NonStop OS. Pro Windows NT, MacOS a OS/2 existuje implementace vývoje komponent OpenDoc na bázi SOM/DSOM. Systém byl vyvinut v polovině 90. let, opuštěn byl v roce 1998 [1] .
IBM SOM je koncepčně podobný objektovému modelu komponent společnosti Microsoft . Oba systémy řeší problém vytvoření standardního formátu knihovny, který lze volat z více než jednoho jazyka. SOM je považován za funkčnější než COM. COM poskytuje dva způsoby volání metod na objektu a objekt může implementovat jednu nebo obě z nich. První je dynamické vyvolání a pozdní vazba (IDispatch) a stejně jako SOM je jazykově nezávislý. Druhý způsob, přes privátní rozhraní, používá tabulku funkcí, kterou lze sestavit v C, nebo použít nižší úroveň kompatibilní virtuální metodickou tabulku objektu C++. Pomocí kompatibilních kompilátorů C++ můžete deklarovat privátní rozhraní jako čistě virtuální třídy C++. Soukromá rozhraní jsou kompromisem mezi funkčností a výkonem. Jakmile bylo rozhraní publikováno do vydaného produktu, nelze jej upravit, protože uživatelské aplikace rozhraní byly zkompilovány pro konkrétní stolní zařízení na nízké úrovni. Toto je příklad problému křehké základní třídy , který může mít za následek DLL peklo , kdy po instalaci nové verze sdílené knihovny přestanou správně fungovat všechny programy používající starou verzi. Chcete-li se tomuto problému vyhnout, vývojáři modelu COM by měli mít vždy na paměti, že rozhraní, která již byla publikována, by neměla být upravována. Pokud chcete přidat nové metody nebo provést jiné změny, musíte definovat nová rozhraní. SOM těmto problémům předchází tím, že poskytuje pouze pozdní vazbu a umožňuje linkeru za běhu znovu sestavovat tabulky za běhu. Změny základních knihoven jsou tedy přepočítány, když jsou načteny do programů, za cenu malého snížení výkonu.
Rozhraní však nelze měnit nejen z technických důvodů, ale ani z hlediska OOP. Rozhraní na rozdíl od třídy nemá výchozí implementaci a může jej implementovat kdokoli, včetně vývojáře třetí strany. Pokud jsou tedy v rozhraní provedeny změny, třídy třetích stran nemohou automaticky podporovat nové rozhraní. Můžete tedy buď místo rozhraní používat pouze třídy, což poskytuje vždy aktuální výchozí implementaci, nebo můžete vývojářům třetích stran zabránit v implementaci potenciálně rozšiřitelného rozhraní, v takovém případě slovo „rozhraní“ ztrácí svůj význam v Podmínky OOP.
SOM je také funkčnější z hlediska plné podpory různých OO jazyků. Zatímco vývoj COM je omezen na použití oříznuté verze C++, SOM podporuje téměř všechny obvyklé funkce a dokonce i několik esoterických. Například SOM podporuje vícenásobnou dědičnost, metatřídy a dynamická volání. Některé z těchto funkcí nejsou dostupné ve většině jazyků, takže mnoho systémů podobných SOM/COM se snadněji implementuje na úkor podpory menší sady jazyků. Plná flexibilita vícejazyčné podpory byla pro IBM důležitá kvůli potřebě podporovat Smalltalk (jednoduchá dědičnost, dynamické spojování) a C++ (vícenásobná dědičnost a statické spojování). Potřeba podpory vícenásobné dědičnosti je mimo jiné důsledkem toho, že místo rozhraní existují pouze třídy. Je třeba poznamenat, že podpora vícenásobné dědičnosti v C++ se liší od CLOS, Dylan, SOM a Python a problémy s vícenásobnou dědičností v C++ nejsou specifické pro SOM.
Nejpatrnějším rozdílem mezi SOM a COM je podpora dědičnosti, kterou COM vůbec nemá. Může se zdát zvláštní, že Microsoft vytvořil systém knihovny objektů, který nepodporuje nejzákladnější princip OOP. Hlavní překážkou je obtížnost určit, kde se v systému nachází základní třída, zatímco se knihovny načítají v potenciálně libovolném pořadí. COM vyžaduje, aby vývojář přesně specifikoval základní třídu v době kompilace, což znemožňuje vložení dalších zděděných tříd doprostřed (alespoň v cizích COM knihovnách).
Naproti tomu SOM používá jednoduchý algoritmus, který prochází stromem dědičnosti, hledá potenciální základní třídu a rozhoduje se na první vhodné. Ve většině případů jde o základní princip dědičnosti. Nevýhodou tohoto přístupu je možnost, že nové verze základní třídy nebudou fungovat navzdory nezměněnému API. Tato možnost existuje v jakémkoli programu, nejen v těch, které používají sdílené knihovny, ale problém je velmi obtížné vystopovat, pokud existuje v kódu někoho jiného. V SOM je jediným řešením plně testovat nové verze knihoven, což není vždy jednoduché.
Srovnání s jinými přístupy bylo provedeno ve zprávě „Binární kompatibilita mezi vydáním a správnost samostatné kompilace“ [2] , zejména Smalltalk, CLOS, Generic C++, SOM, SGI Delta/C++, OBI, Objective-C , Java. Z moderních systémů je nejblíže SOM, pokud jde o poskytování nízkoúrovňové kompatibility s Objective-C, zejména po implementaci nekřehkých ivarů.
Emitory pro C a C++ jsou součástí samotné sady nástrojů SOMobjects Developer Toolkit a umožňují jak volat objektové metody, tak dědit z tříd. Některé kompilátory C++, nejprve MetaWare High C++, poté IBM VisualAge C++, implementovaly funkci Direct-to-SOM. VisualAge C++ pro Windows zavedl tuto funkci ve verzi 3.5 [3] , která byla zároveň poslední verzí, která tuto funkci podporovala.
ObjectREXX, dodávaný s OS/2, je integrován s SOM, což vám umožňuje volat metody na objektech a dědit z tříd. Když byly zdroje ObjectREXX uvolněny komunitě s otevřeným zdrojovým kódem, nebyly přeneseny všechny soubory potřebné pro fungování této integrace a tato funkce nebyla součástí verze s otevřeným zdrojovým kódem. Nějakou dobu byly v úložišti stopy integrace se SOM, které se však nepodařilo zkompilovat a následně bylo vše, co se SOM týkalo, zcela odstraněno.
Balíček SOMSupport VisualAge SmallTalk vám umožňuje volat metody SOM na objekty a vytvářet obaly SOM pro třídy SmallTalk .
IBM ObjectCOBOL původně používal SOM jako objektový systém v režimu Direct-to-SOM. Následně byl ObjectCOBOL portován na Javu a začal používat objektový systém Java namísto SOM.
Některé verze VisualAge for Basic měly integraci SOM [4] . Navíc Lotus Script, zahrnutý v distribuci OpenDoc, může také pracovat s objekty SOM prostřednictvím OpenDoc Direct Scripting (ODDS) [5] .
V SOMObjects Java Client [6] bylo možné volat SOM objekty pouze vzdáleně, přes DSOM. Ukázkový příklad měl třídy, které byly zpřístupněny na serveru DSOM, a potom byl aplet Java hostován na internetovém prostředku, vytvořil vzdálené objekty a zavolal jejich metody. Volání místní metody nejsou k dispozici.
Emitory pro Virtual Pascal byly vyvinuty soukromou osobou, později přeneseny na Free Pascal [7] (pouze OS/2). Umožňují vám volat metody a vytvářet vlastní třídy.
SOMIRIMP.exe [8] (pouze Windows), importér z binární databáze SOM.IR do vazeb Delphi, byl nezávisle vyvinut jinou osobou. Umožňuje volat metody, ale nevytvářet třídy. Na rozdíl od předchozího emitoru implementovaného v C je SOMIRIMP napsán v Delphi a používá samogenerované vazby.
Vývojáři kompilátoru PowerAda vytvořili emitory [9] a příklady použití SOM. PowerAda byla k dispozici pouze na AIX a emitor ke spuštění vyžaduje SOM 3.0 Beta, také pro AIX. SOM 3.0 pro AIX byl ztracen.
Canterbury Modula-2 pro OS/2 měl objektově orientovaná rozšíření podobná Oberon-2 a v profesionální verzi podporoval režim kompilace Direct-to-SOM. [deset]
Společnost Oberon Microsystems oznámila podporu Direct-to-SOM na Mac OS Classic, ale stav tohoto projektu není znám. [jedenáct]
Obvykle vývoj pro SOM probíhá následovně:
Ve spotřebitelském režimu:
Vývojář spustí kompilátor SOM s emitorem pro požadovaný programovací jazyk, který specifikuje, na které IDL soubory požadované knihovny se má navázat. Například:
sc -sada somcm.idl
Emitor vytvoří jeden nebo více souborů ve formátu, kterému rozumí kompilátor zvoleného programovacího jazyka. Pomocí těchto souborů je možné vytvářet objekty popsaných tříd a volat jejich metody.
V režimu producenta:
Vývojář zapisuje své vlastní soubory .idl, které #include jiné soubory .idl, a dědí z tříd popsaných v jiných souborech .idl. Poté vývojář spustí speciální emitor, který vytvoří soubory s pomocným kódem a soubory s prázdnými implementacemi metod tříd.
Například:
sc -sih animals.idl
sc -sc animals.idl
První volání vytvoří animals.ih, který bude obsahovat například implementaci Animals_AnimalNewClass, která spustí somBuildClass2 a předá mu složitou strukturu syntetizovanou ze vstupu .idl. Kromě tohoto volání obsahuje tento soubor samotnou tuto strukturu a některé další pomocné prvky, které by vývojář neměl vůbec měnit. Druhé volání vytvoří animals.c s prázdnými implementacemi metod. IBM C a C++ emitor může pracovat postupně a přidávat prázdné nové metody, aniž by se dotýkal kódu existujících metod.
Kromě toho existují emitory pro vytváření .dll. Emitor IMOD syntetizuje hlavní funkci .dll, emitor DEF syntetizuje soubory .def a .nid.
Emitor je knihovna nazvaná emit*.dll, kde * je volba k argumentu -s kompilátoru SOM. Knihovna musí exportovat proceduru emit (SOM 2.1) nebo emitSL (SOM 3.0), která při volání z kompilátoru SOM provede práci specifickou pro vybraný emitor. Práce může být jakákoli. Pro vytvoření nových emitorů existuje skript newemit.
Zářiče zahrnují IR zářič, který vytváří nebo aktualizuje binární databázi SOM.IR. Tuto databázi lze poté otevřít pomocí rozhraní Interface Repository Framework. To se nejčastěji používá pro vzdálená volání procedur a dynamické programovací jazyky. Takto funguje VisualAge SOMSupport for Smalltalk a ObjectREXX.
Kromě toho standard OpenDoc zahrnuje OpenDoc Direct Scripting (ODDS) a interprety skriptovacích jazyků, které implementují rozhraní ODScriptComponent , tak mohou přistupovat ke třídám SOM prostřednictvím ODDS. Příkladem takového programovacího jazyka je Lotus Script dodávaný s OpenDoc [5] .
Databázi SOM.IR lze také použít k vytvoření vazeb pro kompilované programovací jazyky [12] .
Novell vyvinul most, který zpřístupňuje objekty SOM z jazyků, které podporují automatizaci OLE. Novell ComponentGlue navíc umožňuje aplikacím, které využívají jednu z technologií OLE nebo OpenDoc, používat komponenty vyrobené pomocí jiné technologie a také obalovat část OpenDoc jako komponentu OLE (OCX). To používá obslužný program ctypelib . Při použití tohoto nástroje se během kompilace negeneruje žádný programový kód. V registru je registrována stejná DLL z OpenDoc, která je schopna načíst knihovnu SOM do paměti a vytvářet virtuální tabulky metod, odrazové můstky a další prvky potřebné pro proxy COM objekty za běhu. ComponentGlue obvykle implementuje pouze rozhraní IDispatch, ale pro urychlení je možné deklarovat a implementovat vlastní rozhraní COM označením rozhraní SOM modifikátorem ODdual a dodržením všech pravidel pro rozhraní OLE.
Dalším nástrojem pro integraci SOM a COM je utilita emitcom , která vytváří obaly COM pro třídy SOM v C++. emitcom byl zahrnut do SOM 3.0 Beta (únor 1996), ale nebyl zahrnut do SOM 3.0 Release (prosinec 1996), jako mnoho dalších funkcí.
Je však třeba poznamenat, že protože COM nedělá nic pro vyřešení problému křehké základní třídy, měli byste si dávat pozor na takové mosty. COM wrappery vytvořené emitcom odpovídají nuggetu rozhraní třídy v době vytvoření, a když se rozhraní změní, musí být vytvořeny nové verze wrapperů s novými GUID rozhraní COM, které stále podporují rozhraní COM starých verzí wrapperu. . Rozhraní COM generovaná obslužným programem ctypelib pro třídy SOM označené modifikátorem ODdual by neměla být používána z kompilovaných programovacích jazyků, protože nízkoúrovňová reprezentace takového rozhraní není stabilní. ctypelib obvykle přepíše knihovnu typů COM a neexistuje žádné ustanovení pro paralelní údržbu více různých verzí rozhraní.
Při použití emitorů v kompilovaných programovacích jazycích, jako je C++, emitor C++ dává dojem, že třída SOM je třída C++. somInit je mapován na standardní konstruktor a somAssign je mapován na operator=. Při implementaci jejich tříd však hraje hlavní roli psaní .idl a implementace metod nevypadá jako implementace metod třídy. Chcete-li soubory aktualizovat, musíte neustále volat kompilátor SOM. SOM se ukazuje jako něco cizího programovacím jazykům, jejichž kompilátory nemají vestavěnou podporu pro SOM.
Kompilátor Direct-to-SOM C++ eliminuje potřebu psaní souborů .idl. Soubory .idl jsou generovány na základě hlavičkových souborů C++ DTS, nikoli naopak. Kompilátor DTS C++ tedy poskytuje kompletní, homogenní vývojové prostředí, které vám umožňuje psát vše v jednom jazyce. Práce se som.dll v DTS C++ je podobná práci s objc.dll v Objective-C.
Emitory jsou stále potřeba, ale pouze pro import knihoven třetích stran. Microsoft C++ má schopnost zapisovat #import <něco.tlb>. Totéž by se dalo udělat s IDL v DTS C++, ale to nebylo implementováno. Místo toho musíte použít emitor, který vytvoří soubory .hh požadované kompilátorem DTS C++. Kompilátor DTS C++ podporuje jak běžné třídy C++, tak třídy SOM, které dědí ze SOMObject (explicitně nebo implicitně, s #pragma SOMAsDefault (zapnuto)). Stejně jako u jiného hybridu, Objective-C++, je omezená schopnost míchat třídy z různých hierarchií.
Direct-to-SOM C++ se objevilo v MetaWare High C++ a později bylo duplikováno ve VisualAge C++, navíc tyto implementace nejsou přímo kompatibilní, pouze přes import/export do .idl. V knize "Putting Metaclasses to Work" byl popsán další, třetí známý dialekt DTS C++, jehož kompilátor dosud neexistuje.
Existuje otevřená implementace SOM - somFree [13] . Projekt si nárokuje binární kompatibilitu s původní implementací od IBM. Netlabs.org udržuje implementaci NOM, která je založena na principech SOM, ale není kompatibilní se zdroji ani binárně.
| Komponenty OS/2 a API | |
|---|---|
| Hlavní | |
Manažerské služby | |
| Hry |
|
| jádro OS | |
| Souborové systémy | |
| Grafický subsystém |
|
| Objektový model | SOM
|
| Kompatibilita |
|