Hvad JavaBeans er, og hvad det gør
JavaBeans er ikke et produkt, program eller udviklingsmiljø. Det er begge en central Java-pakke (java.bønner), som Bønner kan bruge til leveret udvidet funktionalitet, og et dokument ( JavaBeans Specifikation), der beskriver, hvordan man bruger klasser og grænseflader i java.bønner pakke til implementering af "Beans-funktionalitet." Klassespecifikationen er en del af basisudgivelsen af Java 1.1, og der skal derfor ikke installeres yderligere software for at kunne bruge den. Tilføjelsen af bønner krævede lidt ændring af Java-sproget i sig selv, selvom flere nye og hårdt nødvendige API'er blev føjet til kernefrigivelsen for at understøtte Beans-funktioner. At læse specifikationen kan være informativ, men soporific. Heldigvis er det valgfrit, hvis du allerede forstår, hvordan og hvorfor du bruger JavaBeans-pakken. Måske forstår du allerede Bønner gennem at læse en underholdende og oplysende serie af artikler om JavaBeans i JavaWorld, for eksempel.
JavaBeans forvandler klasser til softwarekomponenter ved at levere flere nye funktioner. Nogle af disse funktioner er specifikke for bønner. Andre, som serialisering, kan gælde for nogen klasse, bønner eller på anden måde, men er afgørende for forståelsen og brugen af bønner.
Softwarekomponenter har ejendomme, som er attributter for objektet. Tilpasning er processen med at konfigurere en bønne til en bestemt opgave. Den nye håndtering af begivenheder skema i Java 1.1 blev skabt til dels for at lette kommunikationen mellem bønner. Bønner kan dissekeres af IDE'er eller af andre klasser gennem en proces, der kaldes introspektion. Bønner kan være vedvarende (dvs. seriel) i byte-streams til transmission eller lagring, og vedvarende bønner kan være pakket i "JAR-filer" for at lette download og adgang. Endelig er bønner designet til interoperere let med ældre komponentteknologier som ActiveX og LiveConnect og deltage i transaktioner med Object Request Broker-systemer som CORBA.
Lad os se på hver af disse muligheder lidt mere dybtgående.
Egenskaber og tilpasning
Egenskaber, som nævnt ovenfor, er attributter for en bønne. Visuelle egenskaber kan omfatte farve eller skærmstørrelse. Andre egenskaber har muligvis ingen visuel repræsentation: En BrowserHistory Bean kan f.eks. Have en egenskab, der angiver det maksimale antal URL'er, der skal gemmes. Bønner udsættes for setter og getter metoder (kaldet "accessor metoder") for deres egenskaber, så andre klasser eller IDE'er kan manipulere deres tilstand. Processen med at opsætte en Beans egenskaber ved design- eller runtime kaldes tilpasning.
Udvikleren har stor kontrol over adgang og ændring af Beans egenskaber. For en enkel ejendom, skriver udvikleren en metode kaldet setProperty () og en anden kaldte getProperty ().
Søjlediagram
For eksempel, hvis du bruger en Java-aktiveret browser, ser du til venstre en applet, der bruger en lille klasse kaldet Søjlediagram. Det Søjlediagram er den farvede bjælke mellem de to knapper. Søjlediagram mangler kun én ting for at blive en bønne: den implementerer ikke grænsefladen java.io.Serialiserbar (fordi de fleste browsere endnu ikke håndterer Java 1.1, og eksemplet applet ville derfor mislykkes.)
Med undtagelse af at være Serializable, Søjlediagram er en simpel bønne med kun få metoder. Det har ugyldigt setPercent (int pct), der oversvømmer bunden pct procent af bjælken med rødt. Metoden int getPercent () returnerer den aktuelle procentdel, der er gemt i bønnen (dette er bønnens tilstand). Det setPercent () metode kalder også genmaling () hvis det ændrede procentdelen, så den visuelle repræsentation af objektet forbliver opdateret.
Appletkoden kalder op setPercent (getPercent () + 10) når +10% der klikkes på knappen, hvilket forårsager Søjlediagram for at øge sin procentdel (hvis den er <100%). Procent er et eksempel på en Bønnejendom, med setter- og gettermetoder navngivet i overensstemmelse med JavaBeans-specifikationen. Når denne serie fortsætter, vil vi transformere denne ydmyge lille Søjlediagram til en nyttig softwarekomponent, der kan tilsluttes en række applikationer.
Værdien af en indekseret ejendom er en matrix. Indekserede egenskabers adgangsmetoder modtager og returnerer matrixer af værdier i stedet for skalarer. Accessor-metoder kan kaste markerede undtagelser for at rapportere fejltilstande.
Nogle gange er det nyttigt, at en handling opstår, når en bestemt egenskab ved et objekt ændres. Bundet egenskaber få begivenheder til at blive sendt til andre objekter, når ejendommens værdi ændres, hvilket muligvis giver modtageren mulighed for at foretage sig noget. Så en SpreadSheet Bean kan konfigureres til at fortælle en PieChart Bean at tegne sig selv, når dataene i regnearket ændres.
Ofte er visse værdier for ejendomme ulovlige baseret på tilstanden af andre bønner. En bønne kan indstilles til at "lytte" til disse begrænsede egenskaber af andre bønner, og "veto" ændrer det ikke. For eksempel vil en atomreaktors ControlRodArray Bean muligvis forstyrre nogen, der prøver at ændre tilstanden til en DrainReactorCorePump Bean til ON, hvis kontrolstængerne trækkes ud. (Forsøg ikke derhjemme. Sandsynligvis burde ingen bruge JavaBeans til sådanne applikationer lige endnu.)
Når en udvikler forbinder Beans sammen for at oprette en applikation, kan IDE præsentere et egenskabsark, der indeholder alle Beans 'egenskaber og deres aktuelle værdier. (Et egenskabsark er en dialogboks, der bruges til at indstille og / eller se egenskaber, som hvad du får ved at vælge Indstillinger ... i en menu.) Udvikleren indstiller egenskaberne grafisk, som IDE oversætter til opkald til Beans 'setter-metoder, ændring af Beans 'tilstand. Det her tilpasser bønnerne til den bestemte anvendelse.
Brug af lister over egenskaber er ikke altid den bedste måde at håndtere tilpasning af bønner på. Nogle bønner har en tilstand, der er for kompleks til, at den let kan manipuleres på denne måde. Andre bønner ville simpelthen være køligere, hvis der var en mere intuitiv måde at oprette dem på. Forestil dig den dårlige leder, der simpelthen vil se på salgsrapporter og skal finde ud af, hvad de skal skrive i tekstfeltet "Fjern ODBC-datakilde" i et egenskabsark. Ville det ikke være køligere, hvis hun blot kunne trække og slippe et DataSource Bean-ikon (tilpasset med etiketten "Salgsdata", naturligvis) til en DataConnection Bean og derved konfigurere det automatisk? En Beans-udvikler kan integrere et egenskabsark i selve Bean, og IDE bruger derefter denne "tilpasning" til at tilpasse Bean.
De relevante klasser til manipulation af egenskaber og tilpasning findes i java.bønner pakke.
Begivenhedshåndtering
Alt dette samspil mellem bønner forudsætter en måde for dem at kommunikere på. JDK 1.1 definerer en ny begivenhedsmodel som klasser (ikke kun bønner!) bruger til at kommunikere. Faktisk har denne nye begivenhedsmodel fundet vej ind i en af Java's mest anvendte pakker: java.awt!
I den nye begivenhedsmodel registrerer en klasse interesse for aktiviteterne i en anden klasse ved hjælp af en lyttergrænseflade. I virkeligheden er mål objekt (den interesserede part) fortæller kilde objekt (genstanden af interesse), "Lad mig vide, når der sker noget sådant." Når sådan og så sker, "fyrer" kildeobjektet en begivenhed mod målet ved at påkalde målets begivenhedshåndterer med en underklasse af EventObject som argumentet.
Begivenheder kan bruges til at implementere bundne og begrænsede egenskaber. I eksemplet PieChart og SpreadSheet "registrerer" PieChart interesse for enhver ændring i SpreadSheet's (lad os sige) Dataliste ejendom. Når regnearket skal ændre dets Dataliste ejendom, den passerer en DataListChangedEvent (underklasseret fra EventObject), der angiver, hvad der er ændret, til enhver interesseret lytters begivenhedshåndteringsmetode Målet (Lagkagediagram) undersøger derefter begivenheden og træffer passende handlinger.
Eksemplet på atomreaktoren fungerer ens; men i så fald målet vetoer ændringen ved at kaste en undtagelse. Således er verden reddet fra udbredt radioaktiv ødelæggelse.
Det EventObject klasse kan udvides til at oprette brugerdefinerede begivenheder. Klasser kan nu definere og bruge nye begivenhedstyper til at sende meddelelser til hinanden. Dette betyder, at bønner, der kører inde i den samme container, kan kommunikere ved at sende meddelelser rundt. Dette hjælper med at fjerne afhængigheder mellem objekter, som vi ved er en meget god ting.
Brugerdefinerede (og andre) begivenheder stammer fra klassen java.util.EventObject.
Introspektion
Det ret mærkelige udtryk introspektion er Java-tale til processen med programmatisk at analysere en klasses offentlige metoder og medlemmer. Denne proces kaldes også undertiden opdagelse. Den nye afspejling mekanisme i Java-kernen, som kan dissekere et objekt og returnere en beskrivelse af dets indhold, gør introspektion mulig. (Selvom Java kan være reflekterende, endda introspektiv, er omphaloskepsis stadig ikke en del af kernefordelingen.)
Vi har allerede kørt på én applikation af denne kapacitet. Ovenfor beskrev vi en IDE, der kunne konstruere en liste over Bean-egenskaber, der skulle præsenteres for en udvikler. Hvordan kan IDE vide, hvilke egenskaber en bønne har? IDE opdager en bønnes egenskaber på en af to måder: ved at bede bønnen om en beskrivelse af dens egenskaber eller ved at dissekere bønnen ved at undersøge den indad.
En typisk IDE starter med at bede en Bean om et BeanInfo-objekt, der blandt andet beskriver Bean's egenskaber. IDE bruger derefter BeanInfo-objektet til at konstruere et egenskabsark. (Dette forudsættes, at Bean ikke leverer en egen tilpasning.) Hvis Bean ikke ved, hvordan man returnerer et BeanInfo-objekt, introspekterer IDE derefter Bean og scanner listen over metoder til navne, der begynder med sæt og få. Det antager (ved konvention), at disse metoder er accessors for egenskaber, og opretter et nyt egenskabsark baseret på de eksisterende accessor-metoder og de typer af argumenter, disse metoder tager. Så hvis IDE finder metoder som setColor (farve), Farve getColor (), setSize (størrelse)og Størrelse getSize (), så opretter det et ejendomsark med egenskaberne Farve og Størrelseog passende indtastede widgets til indstilling af dem.
Dette betyder, at hvis en udvikler simpelthen følger konventionerne for navngivning af accessormetoder, kan en IDE automatisk bestemme, hvordan man opretter et tilpasningsegenskabsark til komponenten.
Refleksionsmekanismen, der udfører introspektion, er i den nye sprogkernepakke java.lang.reflekteret.
Persistens og emballage
Det er ofte nyttigt at "fryse-tørre" et objekt ved at konvertere dets tilstand til en klods data, der skal pakkes væk til senere brug - eller transmitteres gennem et netværk til behandling andetsteds. Denne proces kaldes serialisering og er en ny funktion i Java-kernen.
En af de enkleste anvendelser til serialisering er at gemme tilstanden for en tilpasset bønne, så en nykonstrueret bønnes egenskaber kan indstilles korrekt ved kørselstid.
Serialisering er også en grundpille i komponentteknologi, hvilket muliggør ordninger med distribueret behandling som CORBA. Hvis et objekt ikke lokalt har de oplysninger, som det har brug for til at udføre sin opgave, kan det sende sig selv til en Request Broker, der serialiserer objektet og sender det et andet sted til behandling. I den fjerne ende rekonstrueres objektet, og den oprindeligt anmodede operation udføres. Dette er også en måde at realisere belastningsbalancering på (for dyre opgaver, dvs. serialisering og deserialisering er ofte ikke billige).
Hvor opbevarer du en gruppe frysetørrede bønner, der er "syltet" på denne måde? Hvorfor i en JAR selvfølgelig! JavaBeans-specifikationen beskriver en KRUKKE fil som en struktureret ZIP-fil, der indeholder flere serielle objekter, dokumentation, billeder, klassefiler osv. med en manifest der beskriver, hvad der er i JAR. En JAR-fil, der indeholder mange komprimerede små filer, kan downloades samlet og dekomprimeres i klientenden, hvilket gør applet-download (for eksempel) mere effektiv. (JAR er temmelig åbenbart et spil på Unix tjære filformat.)
Det java.io pakken giver objekt-serialisering. JavaBeans Specification beskriver formatet på JAR-filer.
Interoperation
Nogle gyngede engang, at det gode ved standarder er, at der er så mange at vælge imellem. Komponentteknologier er ingen undtagelse. Der er mange eksisterende systemer baseret på OLE (eller dets seneste inkarnation, ActiveX), OpenDoc og LiveConnect. JavaBeans er designet til (i det mindste i sidste ende) at samarbejde med disse andre komponentteknologier.
Det er ikke realistisk at forvente, at udviklere opgiver eksisterende investeringer i andre teknologier og genimplementerer alt i Java. Siden udgivelsen af Java 1.1 er de første Beans / ActiveX "bridge" -kits blevet tilgængelige, så udviklere kan linke Beans og ActiveX-komponenter problemfrit til den samme applikation. Java IDL-grænsefladen, som gør det muligt for Java-klasser at fungere med eksisterende CORBA-systemer, skal ud i år.
Mens Beans / ActiveX bridge og Java IDL ikke er en del af JavaBeans standard distribution, afrunder de JavaBeans 'muligheder som en industriel styrke, åben teknologi til bærbar komponentsoftware.
Konklusion
Vi har dækket en masse jord. I denne artikel har du lært, hvad softwarekomponenter er, og hvorfor de er værdifulde. Derefter lærte du om de forskellige egenskaber ved JavaBeans, herunder egenskaber, tilpasning, begivenheder, introspektion, vedholdenhed, emballering og interoperation med ældre komponentsystemer.
I den næste artikel i denne serie får vi dig i gang med at bruge JavaBeans og ser på Bean-egenskaber i dybden: hvordan de fungerer, og hvordan du gør dine Beans tilpasselige. Når vi går videre, vil vi diskutere de nye Java-kerneegenskaber, der gør Beans mulige. Fremtidige artikler i denne serie vil dykke ned i detaljerne i de emner, vi diskuterede i denne måned.
Mark Johnson har en bachelor i computer- og elektroteknik fra Purdue University (1986). Han har 15 års erfaring med programmering i C og to år i C ++ og er en fanatisk tilhænger af Design Pattern-tilgangen i objektorienteret arkitektur, softwarekomponenter i teorien og JavaBeans i praksis. I løbet af de sidste mange år arbejdede han for Kodak, Booz-Allen og Hamilton og EDS i Mexico City og udviklede Oracle og Informix databaseapplikationer til det mexicanske føderale valginstitut og for mexicanske toldvæsener. Han tilbragte det sidste år ved NETdelivery, en internetstart i Boulder, CO. Mark er en farvet Unix-programmør og ser Java som det manglende link mellem de nu allestedsnærværende desktop-klientsystemer og åbent, distribueret, og skalerbare back-ender til virksomheder. Han arbejder i øjeblikket som designer og udvikler for Object Products i Fort Collins, CO.Lær mere om dette emne
- En fremragende sammenligning af JavaBeans og ActiveX kan findes 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 vedligeholder et websted til JavaBeans. På dette site kan du downloade den nyeste BDK (Beans Developer's Kit), læse JavaBeans Specification, surfe gennem en online tutorial og finde ud af de nyeste oplysninger om Beans. //java.sun.com/beans
- Det JavaBeans rådgiver, et lejlighedsvis elektronisk nyhedsbrev, der indeholder Beans-nyheder og tip til udviklere, arkiveres på
//splash.javasoft.com/beans/Advisor.html
- Det Ofte stillede spørgsmål om JavaBeans vedligeholdt af Sun er kl
//splash.javasoft.com/beans/FAQ.html
- Langt om længe, omphaloskepsis er en form for introspektiv meditation, der involverer intens kontemplation af navlen. Tjek Word A Day-webstedet, og udfyld din daglige tale med obskure referencer! //www.wordsmith.org/awad/index.html
Denne historie, "En vandretur i JavaBeans" blev oprindeligt udgivet af JavaWorld.
