Veiledning til det eksterniserbare grensesnittet i Java

1. Introduksjon

I denne veiledningen, vi tar en rask titt på java's java.io. kan utvides grensesnitt. Hovedmålet med dette grensesnittet er å legge til rette for tilpasset serialisering og deserialisering.

Før du går videre, må du sjekke ut serialiseringen i Java-artikkelen. Neste kapittel handler om hvordan du serialiserer et Java-objekt med dette grensesnittet.

Etter det skal vi diskutere de viktigste forskjellene i forhold til java.io Serialiserbar grensesnitt.

2. Den Eksternaliserbar Grensesnitt

Eksternaliserbar strekker seg fra java.io Serialiserbar markørgrensesnitt. Enhver klasse som gjennomføres Eksternaliserbar grensesnittet bør overstyre writeExternal (), readExternal () metoder. På den måten kan vi endre JVMs standardiseringsoppførsel.

2.1. Serialisering

La oss ta en titt på dette enkle eksemplet:

offentlig klasse Landredskaper Eksternaliserbar {privat statisk endelig lang serialVersionUID = 1L; privat strengnavn; privat int-kode; // getters, setters @Override public void writeExternal (ObjectOutput out) kaster IOException {out.writeUTF (navn); out.writeInt (kode); } @ Override public void readExternal (ObjectInput in) kaster IOException, ClassNotFoundException {this.name = in.readUTF (); this.code = in.readInt (); }}

Her har vi definert en klasse Land som implementerer Eksternaliserbar grensesnitt og implementerer de to metodene nevnt ovenfor.

I writeExternal () metoden, legger vi til objektets egenskaper til ObjectOutput strøm. Dette har standardmetoder som writeUTF () til String og writeInt () for int-verdiene.

Neste, for å deserialisere objektet, leser vi fra ObjectInput strøm bruker readUTF (), readInt () metoder for å lese egenskapene i samme eksakte rekkefølge som de ble skrevet i.

Det er en god praksis å legge til serialVersionUID manuelt. Hvis dette ikke finnes, vil JVM automatisk legge til en.

Det automatisk genererte nummeret er avhengig av kompilatoren. Dette betyr at det kan forårsake usannsynlig InvalidClassException.

La oss teste atferden vi implementerte ovenfor:

@Test offentlig ugyldig nårSerializing_thenUseExternalizable () kaster IOException, ClassNotFoundException {Country c = nytt land (); c.setCode (374); c.setName ("Armenia"); FileOutputStream fileOutputStream = ny FileOutputStream (OUTPUT_FILE); ObjectOutputStream objectOutputStream = ny ObjectOutputStream (fileOutputStream); c.writeExternal (objectOutputStream); objectOutputStream.flush (); objectOutputStream.close (); fileOutputStream.close (); FileInputStream fileInputStream = ny FileInputStream (OUTPUT_FILE); ObjectInputStream objectInputStream = ny ObjectInputStream (fileInputStream); Land c2 = nytt land (); c2.readExternal (objectInputStream); objectInputStream.close (); fileInputStream.close (); assertTrue (c2.getCode () == c.getCode ()); assertTrue (c2.getName (). tilsvarer (c.getName ())); }

I dette eksemplet oppretter vi først en Land protesterer og skriver det til en fil. Deretter deserialiserer vi objektet fra filen og verifiserer at verdiene er riktige.

Resultatet av det trykte c2 gjenstand:

Land {name = 'Armenia', code = 374}

Dette viser at vi har deserialisert objektet.

2.2. Arv

Når en klasse arver fra Serialiserbar grensesnitt, samler JVM automatisk også alle feltene fra underklasser og gjør dem serierbare.

Husk at vi kan bruke dette på Eksternaliserbar også. Vi trenger bare å implementere lese / skrive-metodene for hver underklasse i arvshierarkiet.

La oss se på Region klasse nedenfor som utvider vår Land klasse fra forrige avsnitt:

offentlig klasse Region utvider Land implementerer Eksternaliserbar {privat statisk endelig lang serialVersionUID = 1L; privat strengklima; privat dobbeltbefolkning; // getters, setters @Override public void writeExternal (ObjectOutput out) kaster IOException {super.writeExternal (out); out.writeUTF (klima); } @ Override public void readExternal (ObjectInput in) kaster IOException, ClassNotFoundException {super.readExternal (in); this.climate = in.readUTF (); }}

Her la vi til to ekstra egenskaper og serieiserte den første.

Noter det vi ringte også super.writeExternal (ut), super.readExternal (inn) innenfor serialiseringsmetoder for å lagre / gjenopprette feltene i foreldreklassene også.

La oss kjøre enhetstesten med følgende data:

Region r = ny region (); r.setCode (374); r.setName ("Armenia"); r.setClimate ("Middelhavet"); r.setPopulation (120.000);

Her er det deserialiserte objektet:

Region {country = "Country {name =" Armenia ', code = 374}' climate = "Mediterranean", population = null}

Legg merke til det siden vi ikke serielliserte befolkning felt i Region klasse, er verdien på eiendommen null.

3. Eksternaliserbar vs. Serialiserbar

La oss gå gjennom de viktigste forskjellene mellom de to grensesnittene:

  • Serialiseringsansvar

Hovedforskjellen her er hvordan vi håndterer serieiseringsprosessen. Når en klasse implementerer java.io Serialiserbar grensesnitt, tar JVM det fulle ansvaret for serialisering av klasseinstansen. I tilfelle Kan utvides, det er programmereren som skal ta seg av hele serieiserings- og deserialiseringsprosessen.

  • Bruk sak

Hvis vi trenger å serieisere hele objektet, blir Serialiserbar grensesnittet passer bedre. På den andre siden, for tilpasset serialisering kan vi kontrollere prosessen ved hjelp av Eksternaliserbar.

  • Opptreden

De java.io Serialiserbar grensesnitt bruker refleksjon og metadata som forårsaker relativt langsom ytelse. Til sammenligning, den Eksternaliserbar grensesnitt gir deg full kontroll over serialiseringsprosessen.

  • Lesebestilling

Mens du bruker Eksternaliserbar, er det obligatorisk å lese alle feltstatene i nøyaktig rekkefølge slik de ble skrevet. Ellers får vi et unntak.

For eksempel hvis vi endrer leserekkefølgen for kode og Navn eiendommer i Land klasse, en java.io.EOFEeksepsjon vil bli kastet.

I mellomtiden, den Serialiserbar grensesnittet har ikke det kravet.

  • Egendefinert serialisering

Vi kan oppnå tilpasset serialisering med Serialiserbar grensesnitt ved å markere feltet med flyktig nøkkelord. JVM serierer ikke det spesielle feltet, men det vil legge til feltet for lagring av filer med standardverdien. Derfor er det en god praksis å bruke Eksternaliserbar i tilfelle tilpasset serialisering.

4. Konklusjon

I denne korte guiden til Eksternaliserbar grensesnitt diskuterte vi nøkkelfunksjonene, fordelene og demonstrerte eksempler på enkel bruk. Vi gjorde også en sammenligning med Serialiserbar grensesnitt.

Som vanlig er hele kildekoden til opplæringen tilgjengelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found