2. června 2009

Jaký máte vztah k Java anotacím? - výsledky

Poslední anketa se týkala anotací a dopadla následovně (hlasovalo 125 lidí):

  • Používám, ale jen někde (43%)
  • Mám je rád, používám, kde se dá (38%)
  • Nemám je rád, snažím se jim vyhnout (10%)
  • Nevadí mi (8%)


Já sám jsem hlasoval pro "Používám, ale jen někde" a nejsem moc zastáncem používání anotací všude, kde se dá. Osobně nejčastěji používám Hibernate Annotations nebo JPA anotace a Spring a jUnit anotace při psaní testů.

Zeptal jsem se pár kolegů na jejich názor na anotace (1, 2) a v následujícím resumé se to pokusím nějak shrnout:

Argumenty pro:
  • jednoduché, intuitivní - toto se může lišit anotace od anotace, ale dost často je zápis pomocí anotace jednodušší než nějaká jiná podoba konfigurace.

  • větší flexibilita - díky používání anotací může být určité řešení flexibilnější než standardní verze bez anotací. Jako příklad bych uvedl Spring MVC - klasická verze vs. verze s anotacemi. Anotace přináší určitě větší flexibilitu, asi i větší jednoduchost používání a menší nároky na učení se klasického API kontrolerů, ale dle mého názoru to jeden nedostatek má. Zejména u větších projektů se hodí, když má projekt nějakou strukturu, nějaká pravidla a toto se hůře vynucuje pomocí anotací než při používání klasického API. Uvedu jeden konkrétní příklad: myslím, že je vhodné mít odkazy na JSP stránky a URL adresy mimo vlastní Java kód kontrolerů. V klasickém API mám settery na viewname, ale co u anotací? Vytvořím si vlastní předky, ale už to zase bude na úkor nějaké funkcionality, které mi anotace nabízejí.

  • pro popis metadat - anotace mi umožňují přidat klasickým třídám (POJO) nové vlastnosti, které není potřeba implementovat přímo v Java kódu. Např. že je třída resp. metoda deprecated, že je třída volána v transakci pouze pro čtení, že je metoda pouze pro uživatele s rolí READ apod.


Argumenty proti:
  • již není POJO - pokud chcete psát "lehké", testovatelné a flexibilní aplikace (z pohledu budoucích změn), pak je určitě dobré používat POJOs. Jen pak je možné používat dané objekty v různých scénářích a prostředích - testy vs. produkční nasazení, objekty ve webové vrstvě vs. DAO vrstva apod. Neplatí to obecně pro všechny anotace, ale některé anotace vyjadřují určitou implementační závislost nebo předepisují dané třídě určité chování, které je platné jen pro určité použití. Konkrétně třeba @Transactional. Nebo nastavení zabezpečení objektů pomocí anotací, EJB anotace apod.

  • konfigurace aplikace nepatří do Java kódu - já sám mám raději několik konfiguračních souborů, kde najdu veškerou konfiguraci než to vše mít roztroušené po jednotlivých Java třídách. Na to zase většina řekne, že je super vidět u každé třídy hned dané vlastnosti (např. nastavení transakce, zabezpečení) než to hledat někde v separátních souborech. Dle mého názoru je lepší mít konfiguraci oddělenou od Java kódu a mít tak možnost nezávislého nastavení aplikace (nebo jejich částí) pro více prostředí.


Anotace mi přijdou jako velice flexibilní nástroj, ale i tak pořád spíše tíhnu ke klasickému vývoji bez anotací. Ale zase je potřeba se na vše dívat z různých pohledů, takže vlastně nelze obecně říci, co je lepší - takto dopadly i výsledky ankety :).

3 komentáře:

Anonymní řekl(a)...

43 + 38 + 10 + 8 ... ať počítám jak počítám, nějak se nemůžu dopočítat do stovky.

Petr Jůza řekl(a)...

Chybí jen 1% a to je zaokrouhlovací chybička :).

David Mach řekl(a)...

U větších aplikací se rozhodně vyplatí oddělit kód od konfiguračních parametrů. A ne vždy bude aplikaci konfigurovat zrovna programátor...