Jak w temacie. Z tego co czytałem adnotacji można używać zamiast np. xml-i do ustalania jakiś propertiesów, tyle że równie dobrze można w tym celu stworzyć klaskę ze stałymi. Można adnotować metody po to by oznaczyć, że spełniona zostaje jakaś funkcjonalność klasy, ale czy nie łatwiej po prostu użyć interfejsów? Można wykorzystać adnotacje dla metadanych klasy, ale czy nie lepiej użyć javadoców?
Po prostu jakoś umyka mi ten temat. Nie czuję go. Nie widzę sytuacji, w której korzystanie z adnotacji byłoby całkiem naturalnym, eleganckim i w gruncie rzeczy najlepszym wyjściem. Być może nie do końca jeszcze zgłębiłem temat?
Byłbym wdzięczny za wyjaśnienie tej kwestii, szczególnie za jakiś prosty przykład pokazujący, że nic nie nadaje się w danej sytuacji lepiej niż adnotacje.
Ale jakie adnotacje ? mówimy o np: springowych ? oczywista oczywistość - ułatwienie. Adnotacje dają Ci tylko dodatkowe metainformacje - żadne rocket-science
Chodzi mi ogólnie o jakieś fajne wykorzystanie adnotacji. Jeżeli w którymś frameworku, dużo one wnoszą z jakiegoś powodu to też jest to pewien przykład.
Przykłady: @NotNull, @Override, Project Lombok, JAXB.
Powodów jest wiele. Najczęściej dlatego że jest zwięźle i czytelnie. Zamiast dziesiatek linii xmla albo rozszerzania 100 interfejsów możesz mieć np.
@Service
@Transactional
class A{
@Inject
private B dependencyB;
@Inject
private C dependencyC;
}
i voila, masz singletonowy serwis którego metody będą automatycznie objęte transakcjami i automatycznie masz też do niego wstrzyknięte dwa inne singletonowe serwisy.
A teraz pomyśl ile kodu musiałbyś napisać żeby osiągnąć podobny efekt ;]
Poza springowymi magiami przekładajacymi się na tonoxmle bezsensownego klepania kodu adnotacje dają ogromne możliwości instrumentacji kodu.
Przykładowo można za pomocą adnotacji zrobić coś takiego:
interface Function<I, O>{
@NotNull
public O apply(@NotNull I in);
}
Następnie w czasie ładowania każdej klasy, która implementuje ten interfejs możemy dodać kod (programowanie aspektowe), który sprawdzi nam warunki na wejściu, in nie jest null oraz na wyjściu , metoda nie zwraca null.
Co ważne informacja ta będzie ciągnęla się za klasą wszędzie gdzie tylko bedzie się ona pojawiać. W przeciwieństwie do wspomnianych przez @Qbisiek javadoców, które nie są załączane do pliku class.
Innym przykładem, nie związanym z instrumentacją/magią springową, jest testowanie. Zarówno JUnit jak i TestNG budują zestawy testów w oparciu o adnotacje. Te wszystkie @Test, @Before czy @After pozwalają na tworzenie całych konstrukcji związanych z kolejnością testów. Tego nie dało się zrobić w JUnit3, gdzie opierano się na konwencji nazewniczej.
Kolejny przykład to Bean Validation i to w jaki sposób, podobny do tego z JUnita/TestNG, walidator wyznacza reguły poprawności dla danego obiektu. Tego nie zaszyjesz w javadocach, xmlach czy plikach properties. Choć istnieje taka reguła, że jak dajesz możliwość użycia adnotacji to można nadpisać ich ustawienia za pomocą XMLa, ale takie nadpisanie jest zazwyczaj "punktowe", a nie "obszarowe".
@Shalom, @Koziołek, dzięki, ale nie do końca pojmuję jak z paru adnotacji powstaje ta cała magia. Rozumiem, że przykłady są zaczerpnięte z frameworków, które już te gotowe adnotacje udostępniają? Być może nie wyraziłem się zbyt jasno, ale bardziej by mnie interesowało, jak napisać własne adnotacje tego typu, lub jak działają te gotowe, że działają.
Z tego co wiem, to adnotacja sama w sobie jest tylko takim jakby zbiorem informacji. Musi więc istnieć jakaś klasa, czy coś co przeleci po wszystkich klasach w projekcie w poszukiwaniu adnotacji, aby je odpowiednio przetworzyć i sprawdzić, czy coś np. jest null czy not null. Tutaj dochodzimy do momentu, gdzie pojawia się dziura w moim ogarnianiu jak to zrobić. Być może dlatego, że rozwiązaniem jest apectJ, z którym nie miałem okazji się pobawić? (czy coś innego?)
Jeszcze zastanawia mnie jak to jest ładnie zrobione, że do niektórych adnotacji eclipse wyświetla odpowiednie komunikaty? Np. przy @Override, o którym wspomniał @Wibowit. Jeżeli wstawimy tą adnotację przy metodzie, która tak naprawdę nic nie przesłania to dostaniemy, odpowiedni error w eclipsie.
@Qbisiek > https://github.com/Koziolek/postconstruct/tree/master/src/main/java/pl/koziolekweb/guice dodanie wsparcia dla @PostConstruct w Guice 3.0.
https://github.com/Koziolek/postconstruct/blob/master/src/main/java/pl/koziolekweb/guice/PostConstructMethodPredicate.java - predykat określający czy metoda jest zaadnotowana.
https://github.com/Koziolek/postconstruct/blob/master/src/main/java/pl/koziolekweb/guice/PostConstructInjectionListener.java - wyszukanie i uruchomienie wszystkich zaadnotowanych metod (w kolejności "losowej").
Qbisiek napisał(a):
Z tego co czytałem adnotacji można używać zamiast np. xml-i do ustalania jakiś propertiesów,
Ja na przykład wole jednak stosować w hibernate adnotacje (javax.persistence) zamiast tworzyć dodatkowy xml
Muszę wyjaśnić jeszcze jedną rzecz - adnotacje same z siebie nic nie robią.
To od kodu (Springa, Hibernata, itp.), który odczytuje te adnotacje zależy, jakie będą one miały skutek.
No tak ale masz w hibernate(bo na razie tylko z tego coś umiem,springa jeszcze sie nie uczyłem) plik główny xml (hibernate.cfg.xml) i albo stosujesz adnotacje albo robisz dodatkowy plik z xml opisujący mapowanie. Ja wole stosować adnotacje
a zna ktoś ładny przykład implementacji metody ala Set<Field> getAnnotatedFields(Object object, Class annotation) ?
Z mojej perspektywy adnotacje mają 2 podstawowe zalety:
- zwiększenie czytelności kodu
- przyspieszenie pracy
W XML-owych konfiguracjach nie zrobimy wszystkiego. Nie bardzo wyobrażam sobie implementację np. takiego Lomboka za pomocą jakichś konfiguracji w XML-u, choć pewnie dałoby się to zrobić. Niemniej jednak, już konfiguracja Logbacka w XML-u zdaje egzamin, ale jest to zupełnie inny przypadek, choć są też loggery korzystające z adnotacji. Dzięki adnotacjom, możemy m.in. zrzucić odpowiedzialność za generowanie powtarzalnego kodu lub wykonywanie powtarzalnych operacji innym programom lub bibliotekom, co oszczędza nasz czas i nerwy, bo możemy się przecież pomylić np. pisząc ręcznie metodę equals().
Przy dynamicznym tworzeniu pól formularza korzystając z entity. Adnotacje mogą powiedzieć programowi czy to ma być textfield lub datefield lub combox itp.