| Järjestelmäobjektimalli (SOMObjects) | |
|---|---|
| Kehittäjä | CIlabit ( IBM , Apple Computer jne.) |
| Käyttöjärjestelmä | MacOS , OS /2 , AIX , Windows , DOS |
| uusin versio | 3.0 (joulukuu 1996 ) |
System Object Model ( SOM ) on CILabsin ( IBM , Apple , OMG, Adobe , Oracle jne.) kehittämä oliopohjaisten dynaamisten kirjastojen järjestelmä . DSOM, CORBA -pohjainen hajautettu versio SOM:sta, jonka avulla objektit voidaan jakaa eri tietokonejärjestelmiin. Toteutuksia on Windows NT, MacOS Classic, OS/2, AIX, DOS, Copland, OS/390, NonStop OS käyttöjärjestelmille. Windows NT:lle, MacOS:lle ja OS/2:lle on toteutettu SOM/DSOM-pohjainen OpenDoc-komponenttien kehitys. Järjestelmä kehitettiin 1990-luvun puolivälissä, se hylättiin vuonna 1998 [1] .
IBM SOM on käsitteellisesti samanlainen kuin Microsoftin komponenttimalli . Molemmat järjestelmät ratkaisevat ongelman luoda standardikirjastomuoto, jota voidaan kutsua useammasta kuin yhdestä kielestä. SOM:n katsotaan olevan toimivampi kuin COM. COM tarjoaa kaksi tapaa kutsua menetelmiä objektissa, ja objekti voi toteuttaa niistä jommankumman tai molemmat. Ensimmäinen on dynaaminen kutsu ja myöhäinen sidonta (IDispatch), ja kuten SOM, se on kielestä riippumaton. Toinen tapa, yksityisen käyttöliittymän kautta, käyttää funktiotaulukkoa, joka voidaan rakentaa C-kielellä, tai käyttää alemman tason yhteensopivaa C++-objektin virtuaalista menetelmätaulukkoa. Käyttämällä yhteensopivia C++-kääntäjiä voit ilmoittaa yksityiset rajapinnat puhtaiksi virtuaalisiksi C++-luokiksi. Yksityiset rajapinnat ovat kompromissi toimivuuden ja suorituskyvyn välillä. Kun käyttöliittymä on julkaistu julkaistuun tuotteeseen, sitä ei voi muokata, koska rajapinnan käyttäjäsovellukset on käännetty tietylle taulukkolaitteelle matalalla tasolla. Tämä on esimerkki haurasta perusluokkaongelmasta , joka voi johtaa DLL-helvettiin , jossa jaetun kirjaston uuden version asennuksen jälkeen kaikki vanhaa versiota käyttävät ohjelmat lakkaavat toimimasta oikein. Tämän ongelman välttämiseksi COM-kehittäjien tulee aina pitää mielessä, että jo julkaistuja rajapintoja ei saa muokata. Jos haluat lisätä uusia menetelmiä tai tehdä muita muutoksia, sinun on määritettävä uudet rajapinnat. SOM estää nämä ongelmat tarjoamalla vain myöhäisen sidoksen ja sallimalla ajonaikaisen linkittäjän rakentaa taulukoita uudelleen lennossa. Siten taustalla oleviin kirjastoihin tehdyt muutokset lasketaan uudelleen, kun ne ladataan ohjelmiin, pienen suorituskyvyn sakon kustannuksella.
Käyttöliittymää ei kuitenkaan voida muuttaa paitsi teknisistä syistä myös OOP:n näkökulmasta. Käyttöliittymällä, toisin kuin luokalla, ei ole oletustoteutusta, ja kuka tahansa, mukaan lukien kolmannen osapuolen kehittäjä, voi ottaa sen käyttöön. Näin ollen, jos käyttöliittymään tehdään muutoksia, kolmannen osapuolen luokat eivät voi automaattisesti tukea uutta käyttöliittymää. Voit siis joko käyttää vain luokkia rajapintojen sijasta, mikä tarjoaa aina ajantasaisen oletustoteutuksen, tai voit estää kolmannen osapuolen kehittäjiä ottamasta käyttöön mahdollisesti laajennettavaa käyttöliittymää, jolloin sana "liitäntä" menettää merkityksensä OOP ehdot.
SOM on myös toimivampi erilaisten OO-kielien täyden tuen suhteen. Vaikka COM-kehitys rajoittuu pelkistetyn C++-version käyttöön, SOM tukee melkein kaikkia tavallisia ominaisuuksia ja jopa muutamia esoteerisia ominaisuuksia. Esimerkiksi SOM tukee useita perintöjä, metaluokkia ja dynaamisia kutsuja. Jotkut näistä ominaisuuksista eivät ole saatavilla useimmilla kielillä, joten monet SOM/COM-kaltaiset järjestelmät on helpompi toteuttaa pienemmän kielen tuen kustannuksella. Monikielisen tuen täysi joustavuus oli tärkeää IBM:lle, koska sen oli tuettava sekä Smalltalkia (yksittäinen periytyminen, dynaaminen linkitys) että C++:aa (moniperintö ja staattinen linkitys). Tarve tukea moniperintöä johtuu muun muassa siitä, että rajapintojen sijaan on vain luokkia. On huomattava, että C++:n moniperinnön tuki eroaa CLOS:ista, Dylanista, SOM:sta ja Pythonista, eivätkä C++:n usean periytymisen ongelmat ole SOM-kohtaisia.
Huomattavin ero SOM:n ja COM:n välillä on perinnön tuki, jota COM:lla ei ole ollenkaan. Saattaa tuntua oudolta, että Microsoft on tuottanut objektikirjastojärjestelmän, joka ei tue OOP:n perusperiaatetta. Suurin este tälle on vaikeus määrittää, missä perusluokka on järjestelmässä, kun kirjastoja ladataan mahdollisesti mielivaltaisessa järjestyksessä. COM edellyttää, että kehittäjä määrittelee perusluokan täsmälleen käännöshetkellä, mikä tekee mahdottomaksi lisätä muita perittyjä luokkia keskelle (ainakin ulkomaisissa COM-kirjastoissa).
Sitä vastoin SOM käyttää yksinkertaista algoritmia, joka kulkee perintöpuun läpi etsiessään mahdollista perusluokkaa ja asettuu ensimmäiseen sopivaan. Useimmissa tapauksissa tämä on perinnön perusperiaate. Tämän lähestymistavan haittapuolena on mahdollisuus, että perusluokan uudet versiot eivät toimi muuttamattomasta API:sta huolimatta. Tämä mahdollisuus on olemassa kaikissa ohjelmissa, ei vain niissä, jotka käyttävät jaettuja kirjastoja, mutta ongelmasta tulee erittäin vaikea jäljittää, jos se on jonkun muun koodissa. SOM:ssa ainoa ratkaisu on testata kirjastojen uusia versioita täysin, mikä ei ole aina helppoa.
Vertailu muihin lähestymistapoihin tehtiin raportissa "Release-to-Release Binary Compatibility and the Correctness of Separate Compilation" [2] , erityisesti Smalltalk, CLOS, Generic C++, SOM, SGI Delta/C++, OBI, Objective-C , Java. Nykyaikaisista järjestelmistä se on lähimpänä SOM:a matalan tason Objective-C-yhteensopivuuden suhteen, varsinkin hauraiden ivarien käyttöönoton jälkeen.
C:n ja C++:n emitterit sisältyvät itse SOMobjects Developer Toolkit -työkaluun, ja niiden avulla voit sekä kutsua objektimenetelmiä että periä luokista. Jotkut C++-kääntäjät, ensin MetaWare High C++, sitten IBM VisualAge C++, ottivat käyttöön Direct-to-SOM-ominaisuuden. VisualAge C++ for Windows esitteli tämän ominaisuuden versiossa 3.5 [3] , joka oli myös viimeinen tätä ominaisuutta tukeva versio.
OS/2:n mukana toimitettu ObjectREXX on integroitu SOM:iin, jolloin voit kutsua menetelmiä objekteissa ja periä luokista. Kun ObjectREXX-lähteet julkaistiin avoimen lähdekoodin yhteisölle, kaikkia tämän integroinnin edellyttämiä tiedostoja ei siirretty, eikä tämä ominaisuus sisältynyt avoimen lähdekoodin versioon. SOM-integraatiosta oli jonkin aikaa arkistossa jälkiä, mutta kääntäminen oli mahdotonta, ja myöhemmin kaikki SOM:iin liittyvä poistettiin kokonaan.
VisualAge SmallTalk SOMSupport - paketin avulla voit kutsua SOM - menetelmiä objekteissa ja luoda SOM - kääreitä SmallTalk - luokille .
IBM ObjectCOBOL käytti alun perin SOM:ia objektijärjestelmänä Direct-to-SOM-tilassa. Myöhemmin ObjectCOBOL siirrettiin Javalle ja alkoi käyttää Java-objektijärjestelmää SOM:n sijaan.
Joissakin VisualAge for Basicin versioissa oli SOM-integraatio [4] . Lisäksi Lotus Script, joka sisältyy OpenDocin jakeluun, voi toimia myös SOM-objektien kanssa OpenDoc Direct Scriptingin (ODDS) avulla [5] .
SOMObjects Java Clientissä [6] oli mahdollista kutsua SOM-objekteja vain etänä DSOM:n kautta. Esittelyesimerkissä oli luokat, jotka asetettiin saataville DSOM-palvelimella, ja sitten Java-sovelma isännöitiin Internet-resurssissa, luotiin etäobjekteja ja kutsuttiin niiden menetelmiä. Paikallisia menetelmäkutsuja ei tarjota.
Yksityinen henkilö on kehittänyt Virtual Pascalin emitterit, jotka siirrettiin myöhemmin Free Pascaliin [7] (vain OS/2). Niiden avulla voit kutsua menetelmiä ja luoda omia luokkia.
SOMIRIMP.exe [8] (vain Windows), tuoja SOM.IR-binääritietokannasta Delphi-sidoksiin, kehitti itsenäisesti toinen henkilö. Voit kutsua menetelmiä, mutta ei luoda luokkia. Toisin kuin edellinen C:ssä toteutettu emitteri, SOMIRIMP on kirjoitettu Delphissä ja käyttää itse luotuja sidoksia.
PowerAda-kääntäjän kehittäjät tekivät emitterit [9] ja esimerkkejä SOM:n käytöstä. PowerAda oli saatavilla vain AIX:lle, ja lähettäjä vaatii SOM 3.0 Beta -version, myös AIX:lle. SOM 3.0 for AIX on kadonnut.
Canterbury Modula-2 for OS/2:ssa oli Oberon-2:n kaltaisia olio-laajennuksia ja se tuki Direct-to-SOM-kääntämistilaa ammattiversiossa. [kymmenen]
Oberon Microsystems on ilmoittanut tuesta Direct-to-SOM:lle Mac OS Classicissa, mutta tämän projektin tila ei ole tiedossa. [yksitoista]
Tyypillisesti SOM:n kehitys etenee seuraavasti:
Kuluttajatilassa:
Kehittäjä ajaa SOM-kääntäjän halutun ohjelmointikielen lähettimellä ja määrittää, mihin halutun kirjaston IDL-tiedostoihin sitoutuu. Esimerkiksi:
sc -sada somcm.idl
Lähettäjä luo yhden tai useamman tiedoston muodossa, jonka valitun ohjelmointikielen kääntäjä ymmärtää. Näiden tiedostojen avulla on mahdollista luoda kuvattujen luokkien objekteja ja kutsua niiden menetelmiä.
Tuottajatilassa:
Kehittäjä kirjoittaa omat .idl-tiedostonsa, jotka #sisältävät muita .idl-tiedostoja ja perivät muissa .idl-tiedostoissa kuvatuista luokista. Sitten kehittäjä käyttää erityistä emitteriä, joka luo tiedostoja apukoodilla ja tiedostoja, joissa on tyhjiä luokkamenetelmien toteutuksia.
Esimerkki:
sc -sih animals.idl
sc -sc animals.idl
Ensimmäinen kutsu luo animals.ih:n, joka sisältää esimerkiksi Animals_AnimalNewClass-toteutuksen, joka suorittaa somBuildClass2:n välittäen sille monimutkaisen rakenteen, joka on syntetisoitu syötteestä .idl. Tämän kutsun lisäksi tämä tiedosto sisältää itse tämän rakenteen ja joitain muita apuelementtejä, joita kehittäjän ei tulisi muuttaa ollenkaan. Toinen kutsu luo animals.c:n tyhjillä menetelmätoteutuksella. IBM:n C- ja C++-emitterit voivat toimia asteittain lisäämällä tyhjiä uusia menetelmiä koskematta olemassa olevien menetelmien koodiin.
Lisäksi on olemassa emitterit .dll-tiedoston luomiseen. IMOD-lähetin syntetisoi .dll-päätoiminnon, DEF-lähetin syntetisoi .def- ja .nid-tiedostot.
Lähettäjä on emit*.dll-niminen kirjasto, jossa * on vaihtoehto SOM-kääntäjän argumentille -s. Kirjaston on vietävä emit (SOM 2.1) tai emitSL (SOM 3.0) -proseduuri, joka SOM-kääntäjästä kutsuttuna suorittaa valitulle emitterille ominaisen työn. Työ voi olla mitä tahansa. Uusien säteilijöiden luomiseksi on olemassa newemit-skripti.
Emitterit sisältävät infrapunalähettimen, joka luo tai päivittää SOM.IR-binaaritietokannan. Tämä tietokanta voidaan sitten avata Interface Repository Frameworkilla. Tätä käytetään yleisimmin etäproseduurikutsuissa ja dynaamisissa ohjelmointikielissä. Näin VisualAge SOMSupport for Smalltalk ja ObjectREXX toimivat.
Lisäksi OpenDoc-standardi sisältää OpenDoc Direct Scripting (ODDS) -skriptikielen tulkit, jotka toteuttavat ODScriptComponent- rajapinnan, ja pääsevät siten SOM-luokkiin ODDS:n kautta. Esimerkki tällaisesta ohjelmointikielestä on Lotus Script, joka toimitetaan OpenDocissa [5] .
SOM.IR-tietokantaa voidaan käyttää myös sidonnan luomiseen käännetyille ohjelmointikielille [12] .
Novell on kehittänyt sillan, joka mahdollistaa SOM-objektien saatavuuden kielillä, jotka tukevat OLE-automaatiota. Lisäksi Novell ComponentGlue antaa sovelluksille, jotka käyttävät jotakin OLE- tai OpenDoc-teknologiaa, käyttää toisella tekniikalla valmistettuja komponentteja sekä kääriä OpenDoc-osan OLE (OCX) -komponentiksi. Tämä käyttää ctypelib - apuohjelmaa . Tätä apuohjelmaa käytettäessä kääntämisen aikana ei luoda ohjelmakoodia. Sama DLL OpenDocista on rekisteröity rekisteriin, joka pystyy lataamaan SOM-kirjaston muistiin ja luomaan virtuaalisia menetelmätaulukoita, ponnahduslaudat ja muut välityspalvelimen COM-objekteille tarvittavat elementit ajon aikana. Yleensä ComponentGlue toteuttaa vain IDispatch-rajapinnan, mutta asioiden nopeuttamiseksi on mahdollista ilmoittaa ja toteuttaa oma COM-rajapinta merkitsemällä SOM-liitäntä ODdual -muuntimella ja noudattamalla kaikkia OLE-rajapintojen sääntöjä.
Toinen työkalu SOM:n ja COM:n integrointiin on emitcom- apuohjelma , joka luo COM-kääreitä SOM-luokille C++:ssa. emitcom sisältyi SOM 3.0 Betaan (helmikuu 1996), mutta se ei sisälly SOM 3.0 -julkaisuun (joulukuu 1996), kuten monet muut ominaisuudet.
On kuitenkin huomattava, että koska COM ei ratkaise hauraita perusluokkaongelmaa, sinun tulee olla varovainen tällaisissa silloissa. Emmitcomin tuottamat COM-kääreet vastaavat luomishetkellä luokan rajapintahippua, ja kun käyttöliittymä muuttuu, kääreistä on luotava uusia versioita uusilla COM-rajapinnan GUID-tunnuksilla, jotka tukevat edelleen vanhojen kääreversioiden COM-liittymiä. . ctypelib-apuohjelman luomia COM-liittymiä ODdual-muuntimella merkityille SOM-luokille ei tule käyttää käännetyistä ohjelmointikielistä, koska tällaisen rajapinnan matalan tason esitys ei ole vakaa. ctypelib korvaa tyypillisesti COM-tyyppikirjaston, eikä siinä ole mahdollisuutta ylläpitää useita eri versioita käyttöliittymästä rinnakkain.
Käytettäessä emittereitä käännetyissä ohjelmointikielissä, kuten C++, C++-emitteri antaa vaikutelman, että SOM-luokka on C++-luokka. somInit on kartoitettu vakiokonstruktoriin ja somAssign on kartoitettu operaattoriin=. Kuitenkin niiden luokkien toteuttamisessa .idl:n kirjoittaminen on tärkeässä roolissa, eikä menetelmien toteuttaminen näytä luokkamenetelmien toteuttamiselta. Sinun on jatkuvasti soitettava SOM-kääntäjälle tiedostojen päivittämiseksi. SOM osoittautuu jotain vierasta ohjelmointikielille, joiden kääntäjillä ei ole sisäänrakennettua tukea SOM:lle.
Direct-to-SOM C++-kääntäjä eliminoi tarpeen kirjoittaa .idl-tiedostoja. .idl-tiedostot luodaan C++ DTS -otsikkotiedostojen perusteella, ei päinvastoin. Näin ollen DTS C++ -kääntäjä tarjoaa täydellisen, homogeenisen kehitysympäristön, jonka avulla voit kirjoittaa kaiken yhdellä kielellä. Työskentely som.dll:n kanssa DTS C++:ssa on samanlaista kuin Objc.dll:n työskentely Objective-C:ssä.
Lähettäjiä tarvitaan edelleen, mutta vain kolmansien osapuolien kirjastojen tuontiin. Microsoft C++:lla on kyky kirjoittaa #import <jotain.tlb>. Sama voitaisiin tehdä IDL:n kanssa DTS C++:ssa, mutta tätä ei toteutettu. Sen sijaan sinun on käytettävä emitteriä, joka luo DTS C++ -kääntäjän vaatimat .hh-tiedostot. DTS C++ -kääntäjä tukee sekä tavallisia C++-luokkia että SOM-luokkia, jotka perivät SOMObjectistä (eksplisiittisesti tai implisiittisesti, #pragma SOMAsDefault (päällä)). Kuten toisessa hybridissä, Objective-C++:ssa, kyky sekoittaa eri hierarkioiden luokkia on rajoitettu.
Direct-to-SOM C++ ilmestyi MetaWare High C++:ssa ja monistettiin myöhemmin VisualAge C++:ssa. Lisäksi nämä toteutukset eivät ole suoraan yhteensopivia, vain tuomalla/viemällä .idl-muotoon. Kirjassa "Putting Metaclasses to Work" kuvattiin toinen, kolmas tunnettu DTS C ++:n murre, jolle ei ole vielä olemassa kääntäjää.
SOM - somFree [13] on avoin toteutus . Projekti vaatii binaariyhteensopivuutta IBM:n alkuperäisen toteutuksen kanssa. Netlabs.org ylläpitää NOM-toteutusta, joka perustuu SOM-periaatteisiin, mutta ei ole lähde- eikä binääriyhteensopiva.
| OS/2 - komponentit ja API:t | |
|---|---|
| Main | |
| Hallintopalvelut _ | |
| Pelit |
|
| OS-ydin | |
| Tiedostojärjestelmät | |
| Grafiikka alijärjestelmä |
|
| Objekti malli | SOM
|
| Yhteensopivuus |
|