Le annotazioni non hanno una performance vincente ... a meno che vengano utilizzate da una fase di generazione del codice per iniettare il codice per te ( articolo ).
Dove le annotazioni hanno una vittoria definitiva è con il concetto di autoconfigurazione , che è la prima caratteristica killer sfruttata da Spring e framework simili.
Le annotazioni migliorano rispetto alle precedenti soluzioni legacy:
- Interfacce marcatore - richiede una classe per "implementare" un'interfaccia senza alcun metodo definito. Utilizzato per la configurazione basata sulla riflessione nel passato.
- File di configurazione: richiede all'utente di conoscere i nomi di classe completi. Ecco come appariva la configurazione di Spring, insieme a Enterprise JavaBeans (EJB).
- Plugin Javadoc - prima che le annotazioni venissero implementate ufficialmente, alcuni programmi esoterici utilizzavano lo strumento
javadoc per fare ciò che ora fanno le annotazioni. Il rovescio della medaglia è che i marcatori javadoc non possono essere riflessi in fase di esecuzione, e devi usare un altro strumento per preelaborare il codice sorgente prima di compilarlo.
Potrebbero essercene stati altri, ma queste sono le tre soluzioni legacy che conosco personalmente. Le annotazioni sono un insieme di strumenti che possono abilitare soluzioni senza essere eccessivamente invasivi per il tuo codice.
Un altro uso che mi è venuto in mente che le annotazioni sostituite era per decisioni basate su riflessioni, in particolare con i test. JUnit richiedeva di estendere una classe base TestCase e denominare tutti i metodi di test con il prefisso test .
Esempio di test JUnit precedente:
public class SomeCoolTestCase : TestCase {
public void testSomethingCool() {
assertEquals(5, 2+2);
}
}
Tutti i metodi di asserzione erano definiti nella classe base e se il prefisso di test era errato il test non veniva eseguito. Cioè tsetSomethingCool() non avrebbe un errore di compilazione, ma non verrebbe eseguito.
Le annotazioni e le importazioni statiche gestivano entrambi i casi in cui i test delle unità non erano più vincolati da queste convenzioni. Le annotazioni hanno risolto il problema in cui il tuo metodo era stato erroneamente assegnato, quindi il compilatore fallirebbe se ti sbagliasse il nome dell'annotazione. Hanno anche reso le funzioni di pre / post test più flessibili del genere. Le importazioni statiche hanno risolto il problema delle funzioni assert presenti in una classe base, quindi puoi accedervi come se facessero parte del test.
Esempio di test JUnit moderno:
import static junit.framework.Assert.*;
@TestCase
public class SomeCoolTestCase {
@Test
public void givenSomethingCool_shouldBeEqual() {
assertEquals(5, 2+2);
}
}
NOTA: mi dispiace per lo scherzo matematico in entrambi i test non riusciti ... Il codice è stato estratto dalla memoria, quindi è probabile che alcune modifiche siano necessarie per la compilazione.