"Hej, Amigo!"

"Hej, Rishi."

"I dag vil jeg give dig en dybere introduktion til annoteringer."

"Som du sikkert allerede ved, er annoteringer specielle ord, der kan sættes ved siden af ​​klasser, felter, metoder og variabler."

"Ja. Jeg møder dem meget ofte."

"Nogle gange kaldes de også metadata . Deres primære formål er at gemme specifikke yderligere oplysninger om metoder, felter og klasser."

"Hvem gemmer de det til?"

"Det er et meget godt spørgsmål."

"Folk skriver annoteringer, hvilket betyder, at nogen skal have brug for dem."

"Annoteringer lader dig gemme yderligere oplysninger om koden og programelementerne, men formelt er de ikke en del af koden."

"Annoteringer kan bruges til at generere XML, bestemme om en metode er forældet, spore fejl osv."

"Her er et eksempel på annoteringer i kode:"

Eksempel
@CatInfo(manager=Catmanager.class, unique=true)
class Cat
{
 @Name("Missy")
 private String name;

 @SuppressWarnings(value = "unchecked")
 void getUniqueCatName()
 {

 }
}

"Som du kan se, kan data gemmes i annoteringer."

"Hvis en annotation kun har ét felt kaldet værdi , kan feltnavnet udelades:"

Eksempel
@SuppressWarnings("unchecked")
void getUniqueCatName()
{

}

"Hvis der ikke er nogen parametre inde i parentesen, så kan de også udelades:"

Eksempel
@Override
void getUniqueCatName()
{

}

"Det er super nemt at oprette din egen annotering. At erklære en annotering er næsten identisk med at erklære en grænseflade."

Eksempel
@interface CatManager
{
 Class manager();
 boolean unique();
 String name() default "Unknown Cat";
}

"Der er kun et par forskelle."

"Først sætter du et «@»-tegn før ordet grænseflade ."

"For det andet kan en annotering have standardværdier. Du bruger ordet standard til at indstille standardværdier . Se eksemplet ovenfor. Disse parametre er valgfrie og kan udelades, når du tilføjer annoteringer."

"Ah. Det hele er nemmere, end jeg troede. Og jeg har undgået dem, ligesom Robo-Djævelen undgår helligt vand. Det er ikke særlig behageligt, når kode har en masse ting, du ikke helt forstår."

"Åh, det er godt, at du mindede mig om - jeg vil gerne fortælle dig mere om annoteringer, der bruges af kompilatoren."

"Der er kun 3 sådanne kommentarer. Nå, tre indtil videre."

@Forældet.

"Du kan annotere en klasse eller en metode med @Deprecated. Dette vil få compileren til at udstede en advarsel (en advarsel er ikke en fejl), og IntelliJ IDEA vil vise denne metode som gennemstreget tekst. Noget som dette  :

Eksempel
Date date = new Date();
int year = date.getYear();

@Tilsidesæt.

"Det anses for at være en god praksis at tilføje @Override-annotationen til metoder, som du tilsidesætter."

"Hvad er det for noget? Viser IDEA ikke allerede, om en metode er tilsidesat eller ej?"

"Først og fremmest er der IDEA og så er der Java-syntaks."

"Og for det andet, hypotetisk, kan du have en situation, hvor en basisklasses metode bliver omdøbt uden en tilsvarende ændring af metodenavnet i underklassen. Programmet vil ikke fungere som forventet, men ingen vil bemærke det. Denne annotation blev opfundet for at forhindre disse situationer i at ske:"

Eksempel
@Override
void getUniqueCatName()
{

}

@SuppressWarnings.

"Nogle gange viser compileren en masse advarsler. Og nogle gange kender vi til «problemerne» og vælger bevidst at bruge den tilsvarende kode, der skaber dem. Du kan bruge denne annotation til at skjule nogle af disse advarsler."

"En programmør kan bruge @SuppressWarnings- annotationen til at fortælle compileren: «Vis ikke en advarsel for denne fejl - det er med vilje.» For eksempel:"

Eksempel
@SuppressWarnings("unchecked")
void getUniqueCatName()
{

}

"Forstået."

"Jeg er ved at blive lidt træt. Jeg vil våde min udtørrede hals. Lad os fortsætte efter en pause, okay?"

"Jo da."