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?


Hvad er en JavaBean helt præcist?
=================================


En JavaBean er blot en [standard](http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html)


1. Alle egenskaber er private (brug [getters/setters](https://en.wikipedia.org/wiki/Mutator_method))
2. En offentlig [no-argument constructor] ([http://en.wikipedia.org/wiki/Nullary\_constructor](https://en.wikipedia.org/wiki/Nullary_constructor))
3. Implementerer [`Serializable`](https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html).


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](https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html):



> 
> 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":


* er et serialiserbart objekt (dvs. det implementerer [`java.io.Serializable`](https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html), og gør det korrekt), som
* har "egenskaber" hvis getters og setters blot er metoder med bestemte navne (som f.eks. `getFoo()` er getteren for "Foo" egenskaben), og
* har en offentlig 0-arg-konstruktør (så den kan oprettes efter ønske og konfigureres ved at indstille dens egenskaber).


Opdatering:


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.

