Hva JavaBeans er, og hva det gjør
JavaBeans er ikke et produkt, program eller utviklingsmiljø. Det er både en kjerne Java-pakke (java.bønner) som Beans kan bruke til å tilby utvidet funksjonalitet, og et dokument ( JavaBeans spesifikasjon) som beskriver hvordan du bruker klassene og grensesnittene i java.bønner pakke for å implementere "Beans funksjonalitet." Klassespesifikasjonen er en del av basisutgivelsen av Java 1.1, og derfor må ingen ekstra programvare installeres for å kunne bruke den. Tilsetningen av bønner krevde liten endring i Java-språket per se, selv om flere nye og sårt nødvendige API-er ble lagt til i kjerneutgivelsen for å støtte Beans-funksjoner. Å lese spesifikasjonen kan være informativ, men soporific. Heldigvis er det valgfritt hvis du allerede forstår hvordan og hvorfor du bruker JavaBeans-pakken. Kanskje du allerede forstår Beans gjennom å lese en underholdende og opplysende serie med artikler om JavaBeans i JavaWorld, for eksempel.
JavaBeans gjør klasser til programvarekomponenter ved å tilby flere nye funksjoner. Noen av disse funksjonene er spesifikke for bønner. Andre, som serialisering, kan gjelde for noen klasse, Bean eller på annen måte, men er avgjørende for forståelsen og bruken av Beans.
Programvarekomponenter har eiendommer, som er attributter til objektet. Tilpasning er prosessen med å konfigurere en bønne for en bestemt oppgave. Den nye hendelseshåndtering skjema i Java 1.1 ble delvis opprettet for å lette kommunikasjonen mellom bønner. Bønner kan dissekeres av IDEer eller av andre klasser gjennom en prosess som kalles introspeksjon. Bønner kan være vedvarte (dvs., seriell) i byte-strømmer for overføring eller lagring, og vedvarende bønner kan være pakket i "JAR-filer" for å lette nedlasting og tilgang. Endelig er Beans designet for å samarbeide enkelt med eldre komponentteknologier som ActiveX og LiveConnect, og delta i transaksjoner med Object Request Broker-systemer som CORBA.
La oss se litt på hver av disse funksjonene.
Egenskaper og tilpasning
Egenskaper, som nevnt ovenfor, er attributter til en bønne. Visuelle egenskaper kan inneholde farge eller skjermstørrelse. Andre egenskaper kan ikke ha noen visuell fremstilling: En BrowserHistory Bean kan for eksempel ha en egenskap som angir det maksimale antallet nettadresser som skal lagres. Bønner utsetter setter og getter metoder (kalt "tilgangsmetoder") for egenskapene deres, slik at andre klasser eller IDEer kan manipulere deres tilstand. Prosessen med å sette opp en Beans egenskaper ved design- eller kjøretid kalles tilpasning.
Utvikleren har stor kontroll over tilgang og modifisering av Beans egenskaper. For en enkel eiendom, skriver utvikleren en metode som heter setProperty () og en annen ringte getProperty ().
BarChart
For eksempel, hvis du bruker en Java-aktivert nettleser, ser du til venstre en applet som bruker en liten klasse som heter BarChart. De BarChart er den fargede linjen mellom de to knappene. BarChart mangler bare én ting for å bli en Bean: den implementerer ikke grensesnittet java.io Serialiserbar (fordi de fleste nettlesere ennå ikke håndterer Java 1.1, og derfor vil applet-eksemplet mislykkes.)
Med unntak av å være Serializable, BarChart er en enkel bønne, med bare noen få metoder. Det har void setPercent (int pct), som oversvømmer bunnen pct prosent av linjen med rødt. Metoden int getPercent () returnerer den nåværende prosentandelen som er lagret i Bean (dette er Bean's state). De setPercent () metoden også kaller male på nytt () hvis den endret prosentandelen, slik at den visuelle representasjonen av objektet holder seg oppdatert.
Appletkoden ringer setPercent (getPercent () + 10) når +10% klikkes på knappen og forårsaker BarChart for å øke prosentandelen (hvis den er <100%). Prosent er et eksempel på en Bønneiendom, med setter- og gettermetoder navngitt i samsvar med JavaBeans-spesifikasjonen. Når denne serien fortsetter, vil vi forvandle denne ydmyke lille BarChart til en nyttig programvarekomponent som kan kobles til en rekke applikasjoner.
Verdien av en indeksert eiendom er en matrise. Indekserte eiendoms tilgangsmetoder mottar og returnerer matriser av verdier i stedet for skalarer. Tilbehørsmetoder kan kaste avmerkede unntak for å rapportere feilforhold.
Noen ganger er det nyttig for en handling å oppstå når en bestemt egenskap til et objekt endres. Bundet eiendommer føre til at hendelser sendes til andre objekter når eiendommens verdi endres, og muligens tillater mottakeren å gjøre noe. Så en regnearkbønne kan være konfigurert til å fortelle en PieChart-bønne å tegne seg selv når regnearkdataene endres.
Ofte er visse verdier for eiendommer ulovlige, basert på tilstanden til andre bønner. En Bean kan settes opp for å "lytte" til disse begrensede egenskaper av andre bønner, og "veto" endrer det ikke liker. For eksempel kan en atomreaktors ControlRodArray Bean være interessert i å forstyrre noen som prøver å endre tilstanden til en DrainReactorCorePump Bean til ON hvis kontrollstavene trekkes ut. (Ikke prøv dette hjemme. Sannsynligvis skal ingen bruke JavaBeans til slike applikasjoner bare ennå.)
Når en utvikler kobler Beans sammen for å opprette et program, kan IDE presentere et eiendomsark som inneholder alle Beans 'egenskaper og deres nåværende verdier. (Et eiendomsark er en dialogboks som brukes til å angi og / eller vise egenskaper, som det du får ved å velge Alternativer ... på en meny.) Utvikleren setter egenskapene grafisk, som IDE oversetter til anrop til Beans 'settermetoder, endre bønnenes tilstand. Dette tilpasser Bønnene for den spesielle applikasjonen.
Å bruke lister over egenskaper er ikke alltid den beste måten å håndtere tilpasning av bønner på. Noen bønner har en tilstand som er for kompleks til at den lett kan manipuleres på denne måten. Andre bønner ville rett og slett vært kulere hvis det var en mer intuitiv måte å sette dem opp på. Tenk deg den dårlige lederen som bare vil se på salgsrapporter, og må finne ut hva du skal skrive inn i "Remote ODBC Data Source" tekstboksen i et eiendomsark. Ville det ikke vært kulere hvis hun bare kunne dra og slippe et DataSource Bean-ikon (tilpasset med etiketten "Salgsdata", selvfølgelig) på en DataConnection Bean, og dermed konfigurere det automatisk? En Beans-utvikler kan legge inn et eiendomsark i selve Bean, og IDE bruker deretter denne "tilpasningen" til å tilpasse Bean.
De relevante klassene for manipulering av egenskaper og tilpasning er i java.bønner pakke.
Hendelsesbehandling
Alt dette samspillet mellom bønner forutsetter en måte for dem å kommunisere på. JDK 1.1 definerer en ny hendelsesmodell som klasser (ikke bare bønner!) bruker for å kommunisere. Faktisk har denne nye hendelsesmodellen funnet veien inn i en av Javas mest brukte pakker: java.awt!
I den nye arrangementsmodellen registrerer en klasse interesse for aktivitetene til en annen klasse ved hjelp av a lyttergrensesnitt. I virkeligheten er mål objektet (den interesserte) forteller kilde objekt (objektet av interesse), "Gi meg beskjed når så og så skjer." Når slik og slik skjer, "fyrer" kildeobjektet en hendelse mot målet ved å påkalle målets hendelsesbehandler med en underklasse på EventObject som argumentet.
Hendelser kan brukes til å implementere begrensede og begrensede egenskaper. I eksemplet PieChart og SpreadSheet ovenfor registrerer PieChart interesse for enhver endring i SpreadSheet's (la oss si) Dataliste eiendom. Når regnearket skal endre det Dataliste eiendom, passerer den en DataListChangedEvent (underklassert fra EventObject), som indikerer hva som har endret seg, til alle interesserte lytters hendelsesbehandlingsmetode Målet (Kake diagram) undersøker deretter arrangementet, og tar passende tiltak.
Atomreaktoreksemplet fungerer på samme måte; men i så fall målet vetoer endringen ved å kaste et unntak. Dermed er verden reddet fra omfattende radioaktiv ødeleggelse.
De EventObject klassen kan utvides for å opprette brukerdefinerte hendelser. Klasser kan nå definere og bruke nye hendelsestyper for å sende meldinger til hverandre. Dette betyr at bønner som kjører i samme container, kan kommunisere ved å sende meldinger. Dette hjelper med å koble avhengighet mellom objekter, som vi vet er A Very Good Thing.
Brukerdefinerte (og andre) hendelser er hentet fra klassen java.util.EventObject.
Introspeksjon
Det ganske rare begrepet introspeksjon er Java-speak for prosessen med å programmere en klasses offentlige metoder og medlemmer. Denne prosessen kalles også noen ganger oppdagelse. Den nye speilbilde mekanisme i Java-kjernen, som kan dissekere et objekt og returnere en beskrivelse av innholdet, gjør introspeksjon mulig. (Selv om Java kan være reflekterende, til og med introspektiv, er omphaloskepsis fortsatt ikke en del av kjernefordelingen.)
Vi har allerede kjørt over en applikasjon av denne muligheten. Ovenfor beskrev vi en IDE som kunne lage en liste over Bean-egenskaper å presentere for en utvikler. Hvordan kan IDE vite hvilke egenskaper en bønne har? IDE oppdager en Beans egenskaper på en av to måter: ved å be Bean om en beskrivelse av dens egenskaper, eller ved å dissekere Bean ved å introspektere den.
En typisk IDE vil starte med å be en Bean om et BeanInfo-objekt, som blant annet beskriver egenskapene til Bean. IDE vil da bruke BeanInfo-objektet til å konstruere et eiendomsark. (Dette antas at Bean ikke gir en egen tilpasning.) Hvis Bean ikke vet hvordan man skal returnere et BeanInfo-objekt, introduserer IDE Bean og skanner listen over metoder for navn som begynner med sett og få. Det forutsetter (ved konvensjon) at disse metodene er aksessorer for egenskaper, og oppretter et nytt eiendomsark basert på tilgangsmetodene som finnes og hvilke typer argumenter metodene tar. Så hvis IDE finner metoder som setColor (Color), Farge getColor (), setSize (størrelse), og Størrelse getSize (), så vil det opprette et eiendomsark med egenskapene Farge og Størrelseog passende typede widgets for å sette dem.
Dette betyr at hvis en utvikler bare følger konvensjonene for å navngi tilgangsmetoder, kan en IDE automatisk bestemme hvordan man skal lage et egendefineringsark for komponenten.
Refleksjonsmekanismen som utfører introspeksjon er i den nye språkkjernepakken java.lang.refleksjon.
Persistens og emballasje
Det er ofte nyttig å "fryse-tørke" et objekt ved å konvertere dets tilstand til en klatt data som skal pakkes bort for senere bruk - eller overføres gjennom et nettverk for behandling andre steder. Denne prosessen kalles serialisering og er en ny funksjon i Java-kjernen.
En av de enkleste bruksområdene for serialisering er å lagre tilstanden til en tilpasset bønne, slik at egenskapene til en nylig konstruert Bean kan innstilles riktig på kjøretid.
Serialisering er også en bærebjelke i komponentteknologi, noe som muliggjør ordninger for distribuert behandling som CORBA. Hvis et objekt ikke har informasjonen lokalt som det trenger for å utføre oppgaven, kan den sende seg selv til en Request Broker, som serielliserer objektet og sender det andre steder for behandling. I den fjerne enden rekonstitueres objektet og den opprinnelig etterspurte operasjonen utføres. Dette er også en måte å realisere lastbalansering på (for dyre oppgaver, det vil si: serialisering og deserialisering er ofte ikke billig).
Hvor oppbevarer du en gruppe frysetørkede bønner som er "syltet" på denne måten? Hvorfor, i en JAR, selvfølgelig! JavaBeans-spesifikasjonen beskriver en KRUKKE filen som en strukturert ZIP-fil som inneholder flere serieobjekter, dokumentasjon, bilder, klassefiler og så videre, med en manifestere som beskriver hva som er i JAR. En JAR-fil, som inneholder mange komprimerte småfiler, kan lastes ned alt i ett og dekomprimeres på klientsiden, noe som gjør nedlasting av appleter (for eksempel) mer effektiv. (JAR er ganske åpenbart et spill på Unix tjære filformat.)
De java.io pakken gir objektserialisering. JavaBeans-spesifikasjonen beskriver formatet til JAR-filer.
Interoperasjon
Noen slynger en gang at det fine med standarder er at det er så mange å velge mellom. Komponentteknologier er ikke noe unntak. Det er mange eksisterende systemer basert på OLE (eller den siste inkarnasjonen, ActiveX), OpenDoc og LiveConnect. JavaBeans er designet for (i det minste til slutt) å samarbeide med disse andre komponentteknologiene.
Det er ikke realistisk å forvente at utviklere forlater eksisterende investeringer i andre teknologier og implementerer alt på Java på nytt. Siden utgivelsen av Java 1.1 har de første Beans / ActiveX "bridge" -settene blitt tilgjengelige, slik at utviklere kan koble Beans og ActiveX-komponenter sømløst til samme applikasjon. Java IDL-grensesnittet, som gjør det mulig for Java-klasser å operere med eksisterende CORBA-systemer, skal ut i år.
Mens Beans / ActiveX-broen og Java IDL ikke er en del av den vanlige JavaBeans-distribusjonen, avrunder de JavaBeans 'evner som en industriell styrke, åpen teknologi for bærbar komponentprogramvare.
Konklusjon
Vi har dekket mye bakken. I denne artikkelen har du lært hva programvarekomponenter er og hvorfor de er verdifulle. Deretter lærte du om de forskjellige egenskapene til JavaBeans, inkludert egenskaper, tilpasning, hendelser, introspeksjon, utholdenhet, emballasje og interoperasjon med eldre komponentsystemer.
I neste artikkel i denne serien kommer vi i gang med å bruke JavaBeans, og ser på Bean-egenskapene i dybden: hvordan de fungerer, og hvordan du kan tilpasse Beans. Når vi går videre, vil vi diskutere de nye Java-kjernefunksjonene som gjør Beans mulig. Fremtidige artikler i denne serien vil fordype seg i detaljene i emnene vi diskuterte denne måneden.
Mark Johnson har en bachelorgrad i data- og elektroteknikk fra Purdue University (1986). Han har 15 års erfaring med programmering i C og to år i C ++, og er en fanatisk tilhengere av Design Pattern-tilnærmingen i objektorientert arkitektur, programvarekomponenter i teorien og JavaBeans i praksis. I løpet av de siste årene har han jobbet for Kodak, Booz-Allen og Hamilton, og EDS i Mexico City, med utvikling av Oracle og Informix databasesøknader for det meksikanske føderale valginstituttet og for meksikanske tollvesen. Han tilbrakte det siste året på NETdelivery, en internettoppstart nå i Boulder, CO. Mark er en farget Unix-programmerer, og ser Java som den manglende koblingen mellom de nå allestedsnærværende stasjonære klientsystemene og åpne, distribuerte, og skalerbare back-end for bedrifter. Han jobber for tiden som designer og utvikler for Object Products i Fort Collins, CO.Lær mer om dette emnet
- En utmerket sammenligning av JavaBeans og ActiveX finnes i Merlin Hughes ' JavaWorld omslagshistorie, "JavaBeans og ActiveX går head to head"
//www.javaworld.com/javaworld/jw-03-1997/jw-03-avb-tech.html
- Sun Microsystems vedlikeholder et nettsted for JavaBeans. På dette nettstedet kan du laste ned den nyeste BDK (Beans Developer's Kit), lese JavaBeans-spesifikasjonen, surfe gjennom en online veiledning og finne ut om den nyeste informasjonen om Beans. //java.sun.com/beans
- De JavaBeans rådgiver, et sporadisk elektronisk nyhetsbrev som inneholder Beans nyheter og tips om utviklere, arkiveres på
//splash.javasoft.com/beans/Advisor.html
- De Vanlige spørsmål om JavaBeans vedlikeholdt av Sun er kl
//splash.javasoft.com/beans/FAQ.html
- Endelig, omphaloskepsis er en form for introspektiv meditasjon som involverer intens kontemplasjon av navlen. Sjekk ut Word A Day-nettstedet, og fyll den daglige talen med uklare referanser! //www.wordsmith.org/awad/index.html
Denne historien, "A walking tour of JavaBeans" ble opprinnelig utgitt av JavaWorld.
