Jeg har forstået, tror jeg, at en "Bean" er en Java-klasse med egenskaber og getters/sætters. Så vidt jeg har forstået, svarer det til en C struct. Er det rigtigt?
Er der også en reel syntaktisk forskel mellem en bean og en almindelig klasse? Er der en særlig definition eller en grænseflade?
Hvorfor er der i grunden et begreb for dette?
Hvad betyder også Serializable
-interface?
En JavaBean er blot en standard
Serializable
.Det er det hele. Det er bare en konvention. Masser af biblioteker er dog afhængige af den.
Med hensyn til Serializable
, fra API-dokumentationen:
Serializability af en klasse er aktiveret af den klasse, der implementerer den java.io.Serializable-grænsefladen. Klasser, der ikke implementerer dette grænseflade vil ikke få nogen af deres tilstand serialiseret eller deserialiseret. Alle undertyper af en serialiserbar klasse er selv serialiserbare. Den serialiseringsgrænseflade har ingen metoder eller felter og tjener kun til at identificere semantikken ved at være serialiserbar.
Med andre ord kan serialiserbare objekter skrives til streams og dermed til filer, objektdatabaser, objektdatabaser, hvad som helst.
Der er heller ingen syntaktisk forskel mellem en JavaBean og en anden klasse - en klasse er en JavaBean, hvis den følger standarderne.
Der er et udtryk for det, fordi standarden gør det muligt for biblioteker at gøre ting programmatisk med klasseinstanser, som man definerer på en foruddefineret måde. Hvis et bibliotek f.eks. ønsker at streame et objekt, som du sender ind i det, ved det, at det kan gøre det, fordi dit objekt er serialiserbart (forudsat at biblioteket kræver, at dine objekter er rigtige JavaBeans).
Der findes et udtryk for det, der får det til at lyde specielt. Virkeligheden er langt fra så mystisk.
Dybest set er det en "Bean":
java.io.Serializable
, og gør det korrekt), somgetFoo()
er getteren for "Foo" egenskaben), ogOpdatering:
Hvad angår Serializable
: Det er intet andet end en "markørgrænseflade" (en grænseflade, der ikke deklarerer nogen funktioner), der fortæller Java, at den implementerende klasse giver samtykke til (og indebærer, at den er i stand til) "serialisering" -- en proces, der konverterer en instans til en strøm af bytes. Disse bytes kan gemmes i filer, sendes over en netværksforbindelse osv. og har nok information til, at en JVM (i det mindste en, der kender objektets type) kan rekonstruere objektet senere -- muligvis i en anden instans af programmet eller endda på en helt anden maskine!
For at kunne gøre det skal klassen naturligvis overholde visse begrænsninger. Den vigtigste af dem er, at alle instansfelter enten skal være primitive typer (int, bool osv.), instanser af en klasse, der også kan serialiseres, eller markeret som transient
, så Java ikke vil forsøge at inkludere dem. (Dette betyder naturligvis, at transient
felter ikke overlever turen over en stream. En klasse, der har transient
-felter, bør være forberedt på at geninitialisere dem om nødvendigt).
En klasse, der ikke kan overholde disse begrænsninger, bør ikke implementere Serializable
(og, IIRC, Java compileren vil ikke engang lade den gøre det).
Med hensyn til den anden del af dit spørgsmål er serialisering en persistensmekanisme, der bruges til at gemme objekter som en sekvens af signerede bytes. Mindre formelt set gemmer den et objekts tilstand, så du kan hente det senere ved at de-serialisere det.