Spørsmål om Java-merknader (+ svar)

Denne artikkelen er en del av en serie: • Java Collections Interview Questions

• Java Type System Interview Questions

• Java-samtalespørsmål om samtidighet (+ svar)

• Spørsmål om Java-klassestruktur og initialisering

• Java 8 intervjuspørsmål (+ svar)

• Minnehåndtering i Java-intervjuspørsmål (+ svar)

• Java Generics intervjuspørsmål (+ svar)

• Intervju med Java Flow Control (+ svar)

• Java-unntaksspørsmål (+ svar)

• Spørsmål om Java-merknader (+ svar) (nåværende artikkel) • Toppspørsmål om vårens rammeverk

1. Introduksjon

Kommentarer har eksistert siden Java 5, og i dag er de allestedsnærværende programmeringskonstruksjoner som gjør det mulig å berike koden.

I denne artikkelen vil vi gjennomgå noen av spørsmålene angående merknader; som ofte blir spurt om tekniske intervjuer og, når det er hensiktsmessig Vi implementerer eksempler for å forstå svarene deres bedre.

2. Spørsmål

Q1. Hva er merknader? Hva er deres typiske brukstilfeller?

Kommentarer er metadata bundet til elementer i kildekoden til et program og har ingen innvirkning på driften av koden de bruker.

Deres typiske bruksområder er:

Informasjon til kompilatoren - med merknader kan kompilatoren oppdage feil eller undertrykke advarsler
Kompileringstid og behandlingstid for distribusjonstid - programvareverktøy kan behandle merknader og generere kode, konfigurasjonsfiler osv.
Kjøretidsbehandling - Kommentarer kan undersøkes i løpetid for å tilpasse oppførselen til et program

Q2. Beskriv noen nyttige kommentarer fra standardbiblioteket.

Det er flere merknader i java.lang og java.lang.annotasjon pakker, de vanligste inkluderer, men ikke begrenset til:

@Overstyring - markerer at en metode er ment å overstyre et element deklarert i en superklasse. Hvis den ikke overstyrer metoden riktig, utsteder kompilatoren en feil
@Foreldet - indikerer at elementet er utfaset og ikke skal brukes. Kompilatoren vil gi en advarsel hvis programmet bruker en metode, klasse eller felt merket med denne kommentaren
@SuppressWarnings - forteller kompilatoren å undertrykke spesifikke advarsler. Mest brukt når du grensesnitt med eldre kode skrevet før generiske opptredener
@FunctionalInterface - introdusert i Java 8, indikerer at typedeklarasjonen er et funksjonelt grensesnitt og hvis implementering kan gis ved hjelp av et Lambda-uttrykk

Q3. Hvordan kan du lage en kommentar?

Kommentarer er en form for et grensesnitt der nøkkelordet grensesnitt innledes med @, og hvis kropp inneholder merknadstype-element erklæringer som ligner veldig på metoder:

public @interface SimpleAnnotation {Strengverdi (); int [] typer (); }

Etter at kommentaren er definert, kan du begynne å bruke den gjennom koden din:

@SimpleAnnotation (value = "an element", types = 1) public class Element {@SimpleAnnotation (value = "an attribute", types = {1, 2}) public Element nextElement; }

Vær oppmerksom på at når du gir flere verdier for matriseelementer, må du legge dem i parentes.

Alternativt kan standardverdier gis så lenge de er konstante uttrykk for kompilatoren:

public @interface SimpleAnnotation {Strengverdi () standard "Dette er et element"; int [] types () standard {1, 2, 3}; }

Nå kan du bruke merknaden uten disse elementene:

@SimpleAnnotation offentlig klasse Element {// ...}

Eller bare noen av dem:

@SimpleAnnotation (verdi = "et attributt") offentlig Element nextElement;

Q4. Hvilke objekttyper kan returneres fra en erklæring om merknadsmetoder?

Returtypen må være en primitiv, String, Klasse, Enum, eller en matrise av en av de forrige typene. Ellers vil kompilatoren kaste en feil.

Her er en eksempelkode som følger dette prinsippet:

enum Complexity {LOW, HIGH} public @interface ComplexAnnotation {Class value (); int [] typer (); Kompleksitetskompleksitet (); }

Det neste eksemplet kan ikke kompileres siden Gjenstand er ikke en gyldig returtype:

public @interface FailingAnnotation {Objektkompleksitet (); }

Q5. Hvilke programelementer kan kommenteres?

Kommentarer kan brukes flere steder i hele kildekoden. De kan brukes på erklæringer om klasser, konstruktører og felt:

@SimpleAnnotation public class Bruk {@SimpleAnnotation private String aField; @SimpleAnnotation public Søk () {// ...}}

Metoder og deres parametere:

@SimpleAnnotation public void aMethod (@SimpleAnnotation String param) {// ...}

Lokale variabler, inkludert sløyfe og ressursvariabler:

@SimpleAnnotation int i = 10; for (@SimpleAnnotation int j = 0; j <i; j ++) {// ...} prøv (@SimpleAnnotation FileWriter writer = getWriter ()) {// ...} fangst (Unntak ex) {// .. .}

Andre merknader:

@SimpleAnnotation public @interface ComplexAnnotation {// ...}

Og til og med pakker, gjennom pakkeinfo.java fil:

@PackageAnnotation-pakke com.baeldung.interview.annotations;

Fra og med Java 8 kan de også brukes på bruk av typer. For at dette skal fungere, må merknaden spesifisere en @Mål kommentar med verdien på ElementType.USE:

@Target (ElementType.TYPE_USE) offentlig @interface SimpleAnnotation {// ...}

Nå kan merknaden brukes på oppretting av klasseinstanser:

ny @SimpleAnnotation Bruk ();

Type rollebesetning:

aString = (@SimpleAnnotation String) noe;

Implementeringsklausul:

offentlig klasse SimpleList implementerer @SimpleAnnotation List {// ...}

Og kaster klausul:

ugyldig aMethod () kaster @SimpleAnnotation Unntak {// ...}

Q6. Er det en måte å begrense elementene der en kommentar kan brukes i?

Ja, det @Mål merknader kan brukes til dette formålet. Hvis vi prøver å bruke en kommentar i en sammenheng der det ikke er aktuelt, vil kompilatoren gi en feil.

Her er et eksempel for å begrense bruken av @SimpleAnnotation kommentar til feltdeklarasjoner bare:

@Target (ElementType.FIELD) offentlig @interface SimpleAnnotation {// ...}

Vi kan passere flere konstanter hvis vi vil gjøre det anvendelig i flere sammenhenger:

@Target ({ElementType.FIELD, ElementType.METHOD, ElementType.PACKAGE})

Vi kan til og med lage en kommentar, slik at den ikke kan brukes til å kommentere noe. Dette kan være nyttig når de deklarerte typene utelukkende er ment for bruk som medlemstype i komplekse merknader:

@Target ({}) offentlig @interface NoTargetAnnotation {// ...}

Q7. Hva er metaanmerkelser?

Er merknader som gjelder andre merknader.

Alle merknader som ikke er merket med @Mål, eller er merket med det, men inkluderer ANNOTATION_TYPE konstant er også meta-merknader:

@Target (ElementType.ANNOTATION_TYPE) offentlig @interface SimpleAnnotation {// ...}

Q8. Hva er gjentatte merknader?

Dette er merknader som kan brukes mer enn én gang på den samme elementdeklarasjonen.

Siden denne funksjonen ble introdusert i Java 8, lagres gjentatte kommentarer av kompatibilitetsgrunner i en container kommentar som genereres automatisk av Java-kompilatoren. For at kompilatoren skal gjøre dette, er det to trinn for å erklære dem.

Først må vi erklære en repeterbar kommentar:

@Repeatable (Schedules.class) public @interface Schedule {String time () default "morning"; }

Deretter definerer vi den inneholder kommentaren med en obligatorisk verdi element, og hvis type må være en matrise av den repeterbare merknadstypen:

public @interface Schedules {Schedule [] value (); }

Nå kan vi bruke @Schedule flere ganger:

@Schedule @Schedule (time = "ettermiddag") @Schedule (time = "night") ugyldig planlagtMetode () {// ...}

Q9. Hvordan kan du hente kommentarer? Hvordan har dette forhold til politikken for oppbevaring?

Du kan bruke Reflection API eller en merkeprosessor for å hente kommentarer.

De @Bevaring kommentar og dens Retensjonspolitikk parameter påvirker hvordan du kan hente dem. Det er tre konstanter i Retensjonspolitikk enum:

RetentionPolicy.SOURCE - gjør at merknaden skal kastes av kompilatoren, men merkeprosessorer kan lese dem
RetentionPolicy.CLASS - indikerer at merknaden er lagt til i klassefilen, men ikke tilgjengelig gjennom refleksjon
Retensjonspolicy.RUNTIME –Annotasjoner blir registrert i klassefilen av kompilatoren og beholdt av JVM ved kjøretid slik at de kan leses reflekterende

Her er en eksempelkode for å lage en kommentar som kan leses ved kjøretid:

@Retention (RetentionPolicy.RUNTIME) public @interface Description {Strengverdi (); }

Nå kan merknader hentes gjennom refleksjon:

Beskrivelse beskrivelse = AnnotatedClass.class.getAnnotation (Description.class); System.out.println (description.value ());

En merkeprosessor kan jobbe med RetentionPolicy.SOURCE, er dette beskrevet i artikkelen Java Annotation Processing and Creating a Builder.

RetentionPolicy.CLASS kan brukes når du skriver en Java bytecode-parser.

Q10. Vil følgende kode kompilere?

@Target ({ElementType.FIELD, ElementType.TYPE, ElementType.FIELD}) offentlig @interface TestAnnotation {int [] verdi () standard {}; }

Nei. Det er en kompileringstidsfeil hvis den samme enumkonstanten vises mer enn en gang i en @Mål kommentar.

Hvis du fjerner duplikatkonstanten, blir koden vellykket:

@Target ({ElementType.FIELD, ElementType.TYPE})

Q11. Er det mulig å utvide kommentarene?

Nei. Kommentarene strekker seg alltid java.lang.annotation.Annotation, som angitt i Java Language Specification.

Hvis vi prøver å bruke strekker klausul i en merknadserklæring, får vi en kompileringsfeil:

public @interface AnAnnotation utvider OtherAnnotation {// Kompilasjonsfeil}

Konklusjon

I denne artikkelen dekket vi noen av de ofte stilte spørsmålene som dukker opp i tekniske intervjuer for Java-utviklere, angående merknader. Dette er på ingen måte en uttømmende liste, og skal bare betraktes som starten på videre forskning.

Vi i Baeldung ønsker deg lykke til i kommende intervjuer.

Neste » Top Spring Framework Interview Questions « Tidligere spørsmål om Java-unntak (+ svar)

streamalism.org