搜索
Component-OrientedProgramminginObject-OrientedLanguagesPeterH.FrohlichandMichaelFranzDepartmentofInformationandComputerScienceUniversityofCalifornia,IrvineIrvine,CA92697-3425,USAFax:+1.949.824.4056phf@acm.org,franz@uci.eduAbstract.Currentapproachestocomponent-orientedprogrammingarebasedontraditionalobject-orientedlanguagesandconcepts.However,mostexistingobject-orientedlanguagesfailtoaddresssubtleinterfacecompatibilityissuesthatbecomeparamountinacomponent-basedset-ting.Weexplorebothsyntacticandsemanticinterfaceincompatibilitiesanddiscusswhytheyarediculttohandle.Wearguethatresolvingtheseincompatibilitiesrequiresbreakingwithafundamentalidiomofobject-orientedlanguages:thesubordinationofmessagestointerfacesandclasses.Weproposeasolutionbasedontheconceptofstand-alonemessagesasfoundintheexperimentalprogramminglanguageLagoonaanddiscussitsrami cations.1IntroductionComponent-orientedprogrammingaimstoreplacetraditionalmonolithicsoft-waresystemswithreusablesoftwarecomponentsandlayeredcomponentframe-works[27].Componentsextendthecapabilitiesofframeworks,whileframeworksprovideanexecutionenvironmentforcomponents.Botharedevelopedbyinde-pendentandmutuallyunawarevendors,andtheircompositionintoarunningsystemisperformedbyathirdparty,possiblytheend-user.Acomponent-basedapproachtosoftwaredevelopmentpromisesmanyad-vantages,almostallofwhichresultfromthepossibilityofvendorsspecializinginasingledomainofexpertise.Forexample,insteadofdevelopingacompletetextprocessingapplication,independentvendorscanconcentrateonprovidingdocumentversioning,spell-checking,hyphenation,orintelligentassistantswithinacommontextprocessingframework.Developmentresourcescanthusbecon-centratedonasinglecomponent(orasingleframework),hopefullyincreasingitsreliabilityandeciencybeyondwhatwouldbepossibleotherwise.Oneofthemostimportantfactorsformakingthevisionofpervasivesoftwarecomponentsarealityareinterfaces.Aninterfaceisanabstractionofallpossibleimplementationsthatcan llacertainroleinthecomposedsystem[18].Thisabstractionallowsustoconcentrateonwhatisrequiredofanimplementation2PeterH.Frohlich,MichaelFranztoful llitstaskandtodisregardirrelevantdetails.Inthecomponent-basedset-ting,interfacesareusedtodescribeboththeassumptionsthatframeworksmakeaboutcomponentsandtheassumptionsthatcomponentsmakeaboutframe-works.However,interfacesareusuallyonlysyntacticinnature,withbehavioralspeci cationsgivenasinformalcomments.Inprogramminglanguages,type-checkingcanbeusedasanapproximation,butthisonlyguardsagainstasubsetoferrors[6,27].Moreelaboratetechniquesalsoexist,forexamplegreyboxspec-i cationsinthere nementcalculus[5].However,behavioralconformanceofanimplementationtoaninterfacecannotingeneralbeprovenautomatically.Inthispaper,wetakethepointofviewofcomponentvendorsasopposedtoframeworkvendors.Themajortaskofacomponentvendoristodevelopasoftwarecomponentthatconformstotheinterfacespeci edbyaframeworkven-dor.Thistaskismorecomplexwhencomponentshavetoconformtomultipleinterfaces,allspeci edbymutuallyunawareframeworkvendors.Forexample,aspecializedhyphenationcomponentforan\exoticlanguagewillonlybeinter-estingtoalimitedmarketsegment.Suchacomponentmightnotbeviableasaproductifitcannotbereusedacrossmultipletextprocessingframeworks.Object-orientedprogramminghasbeendescribedasafoundationtechnol-ogyforcomponents[27,29].Indeed,conventionalobject-orientedprogramminglanguageslikeJava[1]andC++[26]areoftenusedtoimplementsoftwarecom-ponents.Componentinterfaces,ontheotherhand,areusuallydescribedusinganinterfacede nitionlanguage(IDL).TheseIDLsarespeci ctoacertaincompo-nentmodelsuchasCOM[3,10]orCORBA[16],andalsohaveanobject-orientedcharacter.Theresultingcomplexityofthisapproachisdauntingandpromptedustoinvestigatesimpleralternatives[12,13].Inparticular,weareinterestedindesigningaprogramminglanguage|code-namedLagoona|thatprovidesonlywhatisessentialinacomponent-basedsetting,butnotmore.A rstinsightgainedfromthisprojectisthatmostcurrentobject-orientedlanguagesarebythemselvesunsuitableasabasisforcomponent-orientedpro-gramming.Theselanguagesfailtoproperlyaddresscertaininterfaceincompat-ibilitiesthatarisewhenacomponentmustimplementseveralinterfaces,eachde nedbyanindependentframeworkvendor.Futhermore,neitherthecompo-nentvendornorthecomposingend-usercanresolvetheseincompatibilitiesinastraightforwardway.Surprisingly,wecantracetheincompatibilityproblemsbacktoafundamentalidiomfoundinobject-orientedlanguages:thesubordina-tionofmessagestointerfacesandclasses.Ourconclusionisthatbreakingwiththisidiomistheonlycleanwaytosolvetheproblem.Theremainderofthispaperisorganizedasfollows.Section2illustratestheinterfacecompatibilityproblemsthroughaseriesofexamples.Section3analyzessyntacticandsemanticincompatibilitiesindetailandexplainstheirorigin.Sec-tion4introducestheconceptofstand-alonemessagesandshowshowitsolvesthecompatibilityproblemsintheLagoonaprogramminglanguage.Section5givesabriefoverviewofadditionalLagoonalanguagefeatures.Section6re-viewsrelatedworkandcomparesittoourapproach.Section7concludesthepaperwithasummaryofcontributionsandano