| Systemobjektmodel (SOMObjects) | |
|---|---|
| Udvikler | CILabs ( IBM , Apple Computer osv.) |
| Operativ system | MacOS , OS /2 , AIX , Windows , DOS |
| nyeste version | 3.0 (december 1996 ) |
System Object Model ( SOM ) er et system af objektorienterede dynamiske biblioteker udviklet af CILabs ( IBM , Apple , OMG, Adobe , Oracle osv.). DSOM, en CORBA -baseret distribueret version af SOM, der tillader objekter at blive distribueret på tværs af forskellige computersystemer. Der er implementeringer til Windows NT, MacOS Classic, OS/2, AIX, DOS, Copland, OS/390, NonStop OS operativsystemer. For Windows NT, MacOS og OS/2 er der en implementering af SOM/DSOM-baseret OpenDoc-komponentudvikling. Systemet blev udviklet i midten af 1990'erne, det blev opgivet i 1998 [1] .
IBM SOM ligner konceptuelt Microsoft Component Object Model . Begge systemer løser problemet med at skabe et standardbiblioteksformat, der kan kaldes fra mere end ét sprog. SOM anses for at være mere funktionel end COM. COM giver to måder at kalde metoder på et objekt, og et objekt kan implementere en eller begge af dem. Den første er dynamisk invokation og sen binding (IDispatch), og er ligesom SOM sproguafhængig. Den anden måde, gennem en privat grænseflade, bruger en funktionstabel, der kan konstrueres i C, eller brug en kompatibel virtuel metodetabel på lavere niveau af et C++-objekt. Ved at bruge kompatible C++-kompilere kan du erklære private grænseflader som rene virtuelle C++-klasser. Private grænseflader er et kompromis mellem funktionalitet og ydeevne. Når først en grænseflade er blevet publiceret til et frigivet produkt, kan den ikke ændres, fordi brugerapplikationerne til grænsefladen er blevet kompileret til en specifik tabelenhed på et lavt niveau. Dette er et eksempel på et skørt basisklasseproblem, der kan resultere i DLL-helvede , hvor alle programmer, der bruger den gamle version, holder op med at fungere korrekt efter installation af en ny version af et delt bibliotek. For at undgå dette problem bør COM-udviklere altid huske på, at grænseflader, der allerede er blevet offentliggjort, ikke bør ændres. Hvis du vil tilføje nye metoder eller foretage andre ændringer, skal du definere nye grænseflader. SOM forhindrer disse problemer ved kun at give sen binding og tillade runtime-linkeren at genopbygge tabeller i farten. Ændringer i underliggende biblioteker genberegnes således, når de indlæses i programmer, på bekostning af et lille præstationshit.
Grænsefladen kan dog ikke ændres ikke kun af tekniske årsager, men også fra OOP's synspunkt. En grænseflade, i modsætning til en klasse, har ikke en standardimplementering og kan implementeres af alle, inklusive en tredjepartsudvikler. Hvis der foretages ændringer i grænsefladen, kan tredjepartsklasser derfor ikke automatisk understøtte den nye grænseflade. Således kan du enten kun bruge klasser i stedet for grænseflader, hvilket giver en altid opdateret standardimplementering, eller du kan forhindre tredjepartsudviklere i at implementere en potentielt udvidelsesbar grænseflade, i hvilket tilfælde ordet "grænseflade" mister sin betydning i OOP vilkår.
SOM er også mere funktionel med hensyn til fuld understøttelse af forskellige OO-sprog. Mens COM-udvikling er begrænset til at bruge en strippet version af C++, understøtter SOM næsten alle de sædvanlige funktioner og endda nogle få esoteriske. For eksempel understøtter SOM flere arv, metaklasser og dynamiske opkald. Nogle af disse funktioner er ikke tilgængelige på de fleste sprog, så mange SOM/COM-lignende systemer er nemmere at implementere på bekostning af at understøtte et mindre sæt sprog. Den fulde fleksibilitet af flersproget support var vigtig for IBM på grund af behovet for at understøtte både Smalltalk (enkelt nedarvning, dynamisk linking) og C++ (multipel nedarvning og statisk linking). Behovet for at understøtte multipel nedarvning er blandt andet en konsekvens af, at der i stedet for grænseflader kun er klasser. Det skal bemærkes, at C++'s understøttelse af multipel nedarvning adskiller sig fra CLOS, Dylan, SOM og Python, og C++'s multiple nedarvningsproblemer er ikke specifikke for SOM.
Den mest bemærkelsesværdige forskel mellem SOM og COM er understøttelsen af arv, som COM slet ikke har. Det kan virke mærkeligt, at Microsoft har produceret et objektbibliotekssystem, der ikke understøtter det mest grundlæggende princip i OOP. Den største hindring for dette er vanskeligheden ved at bestemme, hvor basisklassen er i systemet, mens bibliotekerne indlæses i en potentielt vilkårlig rækkefølge. COM kræver, at udvikleren specificerer basisklassen nøjagtigt på kompileringstidspunktet, hvilket gør det umuligt at indsætte andre nedarvede klasser i midten (i hvert fald i udenlandske COM-biblioteker).
I modsætning hertil bruger SOM en simpel algoritme, der krydser arvetræet på udkig efter en potentiel basisklasse og bestemmer sig for den første passende. I de fleste tilfælde er dette det grundlæggende princip for arv. Ulempen ved denne tilgang er muligheden for, at nye versioner af basisklassen ikke fungerer på trods af den uændrede API. Denne mulighed findes i ethvert program, ikke kun dem, der bruger delte biblioteker, men problemet bliver meget vanskeligt at spore, hvis det findes i en andens kode. I SOM er den eneste løsning fuldt ud at teste nye versioner af biblioteker, hvilket ikke altid er let.
Sammenligning med andre tilgange blev foretaget i rapporten "Release-to-Release Binary Compatibility and the Correctness of Separate Compilation" [2] , især Smalltalk, CLOS, Generic C++, SOM, SGI Delta/C++, OBI, Objective- C , Java. Af moderne systemer er det tættest på SOM med hensyn til at levere objektiv-C-kompatibilitet på lavt niveau, især efter implementeringen af ikke-skrøbelige ivars.
Emittere til C og C++ er inkluderet i selve SOMobjects Developer Toolkit og giver dig mulighed for både at kalde objektmetoder og arve fra klasser. Nogle C++-compilatorer, først MetaWare High C++, derefter IBM VisualAge C++, implementerede Direct-to-SOM-kapacitet. VisualAge C++ til Windows introducerede denne funktion i version 3.5 [3] , som også var den sidste version, der understøttede denne funktion.
ObjectREXX, der leveres med OS/2, er integreret med SOM, så du kan kalde metoder på objekter og arve fra klasser. Da ObjectREXX-kilderne blev frigivet til open source-fællesskabet, blev alle de filer, der var nødvendige for at denne integration kunne fungere, ikke overført, og denne funktion var ikke inkluderet i open source-versionen. I nogen tid var der spor af integration med SOM i depotet, men det var umuligt at kompilere, og efterfølgende blev alt relateret til SOM fuldstændigt fjernet.
VisualAge SmallTalk SOMSupport-pakken giver dig mulighed for at kalde SOM-metoder på objekter og oprette SOM-indpakninger til SmallTalk- klasser .
IBM ObjectCOBOL brugte oprindeligt SOM som et objektsystem i Direct-to-SOM-tilstand. Efterfølgende blev ObjectCOBOL overført til Java og begyndte at bruge Java-objektsystemet i stedet for SOM.
Nogle versioner af VisualAge for Basic havde SOM-integration [4] . Derudover kan Lotus Script, inkluderet i distributionen af OpenDoc, også arbejde med SOM-objekter gennem OpenDoc Direct Scripting (ODDS) [5] .
I SOMObjects Java Client [6] var det muligt kun at kalde SOM-objekter eksternt via DSOM. Demoeksemplet havde klasser, der blev gjort tilgængelige på DSOM-serveren, og derefter blev Java-appletten hostet på en internetressource, oprettet fjernobjekter og kaldt deres metoder. Lokale metodeopkald leveres ikke.
Emittere til Virtual Pascal blev udviklet af en privatperson, senere overført til Free Pascal [7] (kun OS/2). De giver dig mulighed for at kalde metoder og oprette dine egne klasser.
SOMIRIMP.exe [8] (kun Windows), en importør fra den binære SOM.IR-database til Delphi-bindinger, blev uafhængigt udviklet af en anden person. Giver dig mulighed for at kalde metoder, men ikke oprette klasser. I modsætning til den tidligere emitter implementeret i C, er SOMIRIMP skrevet i Delphi og bruger selvgenererede bindinger.
Udviklerne af PowerAda-kompileren lavede emittere [9] og eksempler på brug af SOM. PowerAda var kun tilgængelig på AIX, og emitteren kræver SOM 3.0 Beta, også for AIX, for at køre. SOM 3.0 til AIX er gået tabt.
Canterbury Modula-2 til OS/2 havde objektorienterede udvidelser svarende til Oberon-2 og understøttede Direct-to-SOM-kompileringstilstand i den professionelle version. [ti]
Oberon Microsystems har annonceret understøttelse af Direct-to-SOM på Mac OS Classic, men status for dette projekt er ukendt. [elleve]
Typisk forløber udviklingen for SOM som følger:
I forbrugertilstand:
Udvikleren kører SOM-kompileren med en emitter for det ønskede programmeringssprog, som angiver, hvilke IDL-filer i det ønskede bibliotek der skal bindes til. For eksempel:
sc -sada somcm.idl
Senderen opretter en eller flere filer i det format, som compileren af det valgte programmeringssprog forstår. Ved hjælp af disse filer bliver det muligt at oprette objekter af de beskrevne klasser og kalde deres metoder.
I producertilstand:
Udvikleren skriver sine egne .idl-filer, som #inkluderer andre .idl-filer, og arver fra klasserne beskrevet i andre .idl-filer. Derefter kører udvikleren en speciel emitter, der vil oprette filer med hjælpekode og filer med tomme implementeringer af klassemetoder.
For eksempel:
sc -sih animals.idl
sc -sc animals.idl
Det første kald vil oprette animals.ih, som f.eks. vil indeholde en implementering af Animals_AnimalNewClass, der vil køre somBuildClass2 og videregive en kompleks struktur syntetiseret fra inputtet .idl. Ud over dette kald indeholder denne fil selve strukturen og nogle andre hjælpeelementer, som udvikleren slet ikke bør ændre. Det andet kald vil oprette animals.c med tomme metodeimplementeringer. IBM's C og C++ emitter kan arbejde trinvist og tilføje tomme nye metoder uden at røre ved koden for eksisterende metoder.
Derudover er der udsender til oprettelse af .dll. IMOD-emitteren syntetiserer .dll-hovedfunktionen, DEF-emitteren syntetiserer .def- og .nid-filer.
Senderen er et bibliotek kaldet emit*.dll, hvor * er en mulighed for -s-argumentet for SOM-kompileren. Biblioteket skal eksportere en emit (SOM 2.1) eller emitSL (SOM 3.0) procedure, der, når den kaldes fra SOM compileren, udfører arbejde specifikt for den valgte emitter. Arbejdet kan være hvad som helst. For at oprette nye emittere er der et newemit-script.
Sendere inkluderer en IR-emitter, der opretter eller opdaterer den binære SOM.IR-database. Denne database kan derefter åbnes ved hjælp af Interface Repository Framework. Dette bruges mest til fjernprocedurekald og dynamiske programmeringssprog. Sådan fungerer VisualAge SOMSupport for Smalltalk og ObjectREXX.
Derudover inkluderer OpenDoc-standarden OpenDoc Direct Scripting (ODDS), og scriptsprogfortolkere, der implementerer ODScriptComponent -grænsefladen, kan derved få adgang til SOM-klasser via ODDS. Et eksempel på et sådant programmeringssprog er Lotus Script, der leveres med OpenDoc [5] .
SOM.IR-databasen kan også bruges til at oprette bindinger til kompilerede programmeringssprog [12] .
Novell har udviklet en bro, der gør SOM-objekter tilgængelige fra sprog, der understøtter OLE Automation. Derudover tillader Novell ComponentGlue applikationer, der bruger en af OLE- eller OpenDoc-teknologierne, at bruge komponenter, der er fremstillet ved hjælp af en anden teknologi, samt at indpakke OpenDoc-delen som en OLE (OCX)-komponent. Dette bruger ctypelib -værktøjet . Når du bruger dette værktøj, genereres der ingen programkode under kompileringen. Den samme DLL fra OpenDoc er registreret i registreringsdatabasen, som er i stand til at indlæse SOM-biblioteket i hukommelsen og skabe virtuelle metodetabeller, springbrætter og andre elementer, der er nødvendige for proxy-COM-objekter under kørsel. Normalt implementerer ComponentGlue kun IDispatch-grænsefladen, men for at fremskynde tingene er det muligt at deklarere og implementere din egen COM-grænseflade ved at markere SOM-grænsefladen med ODdual-modifikatoren og overholde alle reglerne for OLE-grænseflader.
Et andet værktøj til at integrere SOM og COM er emitcom -værktøjet , som opretter COM-indpakninger til SOM-klasser i C++. emitcom var inkluderet i SOM 3.0 Beta (februar 1996), men var ikke inkluderet i SOM 3.0 Release (december 1996), ligesom mange andre funktioner.
Det skal dog bemærkes, at da COM ikke gør noget for at løse det skøre basisklasseproblem, bør du være på vagt over for sådanne broer. De COM-indpakninger, der er produceret af emitcom, svarer til klassens grænsefladeklump på oprettelsestidspunktet, og når grænsefladen ændres, skal der oprettes nye versioner af indpakningerne med nye COM-grænseflade-GUID'er, der stadig understøtter COM-grænsefladerne i de gamle wrapperversioner . De COM-grænseflader, der genereres af ctypelib-værktøjet til SOM-klasser markeret med ODdual-modifikatoren, bør ikke bruges fra kompilerede programmeringssprog, fordi lavniveau-repræsentationen af en sådan grænseflade ikke er stabil. ctypelib overskriver typisk COM-typebiblioteket, og der er ingen mulighed for at vedligeholde flere forskellige versioner af en grænseflade parallelt.
Når du bruger emittere i kompilerede programmeringssprog såsom C++, giver C++ emitter det udseende, at SOM-klassen er en C++-klasse. somInit tilknyttes standardkonstruktøren, og somAssign tilknyttes operator=. Men når de implementerer deres klasser, spiller skrivning af .idl en stor rolle, og implementeringen af metoder ligner ikke implementeringen af klassemetoder. Du skal konstant ringe til SOM-kompileren for at opdatere filerne. SOM viser sig at være noget fremmed for programmeringssprog, hvis compilere ikke har indbygget understøttelse af SOM.
Direct-to-SOM C++ compileren eliminerer behovet for at skrive .idl-filer. .idl-filer genereres baseret på C++ DTS-header-filer, ikke omvendt. DTS C++ compileren giver således et komplet, homogent udviklingsmiljø, der giver dig mulighed for at skrive alt på ét sprog. At arbejde med som.dll i DTS C++ svarer til at arbejde med objc.dll i Objective-C.
Sendere er stadig nødvendige, men kun til import af tredjepartsbiblioteker. Microsoft C++ har evnen til at skrive #import <noget.tlb>. Det samme kunne gøres med IDL i DTS C++, men dette blev ikke implementeret. I stedet skal du anvende en emitter, der vil skabe de .hh-filer, der kræves af DTS C++-kompileren. DTS C++ compileren understøtter både almindelige C++ klasser og SOM klasser, der arver fra SOMObject (eksplicit eller implicit, med #pragma SOMAsDefault (on)). Som med en anden hybrid, Objective-C++, er muligheden for at blande klasser fra forskellige hierarkier begrænset.
Direct-to-SOM C++ dukkede op i MetaWare High C++ og blev senere duplikeret i VisualAge C++, desuden er disse implementeringer ikke direkte kompatible, kun gennem import/eksport til .idl. I bogen "Putting Metaclasses to Work" blev en anden, tredje kendt dialekt af DTS C++ beskrevet, hvor compileren endnu ikke eksisterer.
Der er en åben implementering af SOM - somFree [13] . Projektet hævder binær kompatibilitet med den oprindelige implementering fra IBM. Netlabs.org vedligeholder en NOM-implementering, der er baseret på SOM-principper, men er hverken kilde- eller binærkompatibel.
| OS/2 - komponenter og API'er | |
|---|---|
| Hoved | |
Management Services | |
| Spil |
|
| OS kerne | |
| Filsystemer | |
| Grafik undersystem |
|
| Objektmodel | SOM
|
| Kompatibilitet |
|