Adnotacje czy metody wirtualne
Jacek Czerwinski
fajerwerki uniwersyteckiego intelektu, ale nie najgorzej - servlet,
Wicket, JPA i inne), zauwazylem, ze w pewnym okresie w klasy dawalem
sporo metod zwracajacych informacje organizacyjne (string Menu, string
Dokumentacyjny, przynależnosc do jakiejs nadrzednej koncepcji czyli
klasy 'parent'), w nowszych testowalem w boju wlasne adnotacje
@Retention(RetentionPolicy.RUNTIME).
Spostrzeżenie sa m.in. takie:
0) wykluczam zewnetrzne XML, ja juz sie nie zmienie i literowki,
zgodnosc typow musi sprawdzac kompilator.
a) adnotacja jest skuteczna dla klasy zaladowanej, nie musza istniec
obiekty. Korzystne przy wickecie.
b) metody wirtualne zwl abstrakcyjne daja fajny przymus, adnotacje nie
jest przymusowa.
c) wydajnosc na tym etapie mnie jeszcze nie interesuje. Nie testowalem.
d) adnotacje maja typy podstawowe i wskazanie na klase, byc moze z
przymusem dziedziczenia z hierarchii. Typy podstawowe nie sa szczytem
szczescia, ale wystarczy. Wskazanie na klase jest kochane jak to polubic
i dobrze uzyc.
e) paradoksalnie wielkosc Managera korzystajacego z tych informacji nie
rozni sie duzo. W tym srodowisku dzialanie na poziomie klas bez obiektow
jest bardzo fajne, jesli jest konsekwentne. Najgorszy jest manager
mieszany (klasa-obiekt)
f) adnotacja skupia w 1-2 liniach, metody wirtualne sa znacznie dluzsze.
g) obowiazki, kontrola i narzucanie jest wieksza przy metodach
wirtualnych. Na adnotacjach mozna troszke nad tym popracowac, ale tylko
do pewnego stopnia.
Chyba bede zapewnial czystosc rozwiazania w filozofii gdzies wyczytanej:
adnotacja to metadana, nie wplywajaca na dzialanie tej klasy (klasa nie
jest nawet swiadoma tego), jest to informacja dla innych czesci systemu.
Czyli metody nie wnoszace do dzialania TEJ klasy bede eliminowal na
rzecz adnotacji.
Pytanie: czy to dobra filozofia?
Jacek Czerwinski
> Ja spojrzalem na sursy wiekszego projektu typu "przemyslowego" (tzn nie
> fajerwerki uniwersyteckiego intelektu, ale nie najgorzej - servlet,
> Wicket, JPA i inne), zauwazylem, ze w pewnym okresie w klasy dawalem
> sporo metod zwracajacych informacje organizacyjne (string Menu, string
> Dokumentacyjny, przynależnosc do jakiejs nadrzednej koncepcji czyli
> klasy 'parent'),
Doraznie w tej chwili mysle o grupowaniu stron www w grupy, breadcrumbs,
moduly, katalogi pewnych podobnych obiektowych funkcjonalnosci itd
Ale pytanie zadaje ogolnie: jak wybierac sposob zaprojektowania, kiedy
adnotacje, kiedy metody zwracajace proste informacje.
sielim
Użytkownik "Jacek Czerwinski" <x...@y.z.pl> napisał w wiadomości
news:i5r93k$fn2$1...@news.onet.pl...
Moim zdaniem niezła, ale jednak trochę 'słaba' w sensie definicji ;)
Weź np. poprawkę na wzorce projektowe, które czasem nakłaniają do tego,
by dzielić na klasy tam, gdzie można wszystko zrobić w jednej klasie.
Np. wzorzec state machine - można zrealizować w jednej klasie,
a można z każdego stanu zrobić osobną klasę i do tego klasa 'nadrzędna'
(maszyna zarządzajaca przejściami między stanami). Zgodnie z twoją
filozofią rozbicie StateMachine na więcej klas spowoduje, że w klasach
State zaczną się pojawiać adnotacje zamiast metod. Nie jestem pewien,
czy to koniecznie dobry kierunek.
Na pewno dobrą zasadą jest próba mieszczenia w adnotacjach
meta-opisu kodu, czyli np. powiązania z wymaganiami (@Requirement),
opisanie niektórych rozwiązań projektowych itp. Wyobrażam sobie wtedy
fajne narzędzia, które np. trawersują po całym kodzie i sprawdzają ,czy np.
każda klasa dziedzicząca po ActionSupport (struts) jest opisana tagiem
@Requirement - czyli czy jest powiązanie z dokumentacją analityczną.
Kiedyś mieliśmy też automat, który po identyfikatorach wymagań wiązał
obiekty z opisami w helpie do aplikacji - to już trochę więcej, niż
meta-opis, bo chodzi wchodzi w funkcjonalność (help).
Waldek Kot
> Chyba bede zapewnial czystosc rozwiazania w filozofii gdzies wyczytanej:
> adnotacja to metadana, nie wplywajaca na dzialanie tej klasy (klasa nie
> jest nawet swiadoma tego), jest to informacja dla innych czesci systemu.
> Czyli metody nie wnoszace do dzialania TEJ klasy bede eliminowal na
> rzecz adnotacji.
> Pytanie: czy to dobra filozofia?
Cześć,
Dobra jako filozofia, jako religia nie ;-)
Do tego co opisujesz, czyli informacji organizacyjnych, to specjalnych
przewag jednego czy drugiego nie widzę. Wciąż jednak, tego rodzaju
informacje bardziej naturalnie pasują mi jako metadane, więc uważam,
że trochę lepiej jest tu użyć adnotacji. Jako czytelnik takiego kodu
też chyba prędzej zrozumiałbym intencje autora.
Akurat w przypadku informacji organizacyjnych najważniejsza wydają mi
się spójna konwencja i aktualność oraz dobra komunikacja tej konwencji
do innych osób. W tym sensie obydwa podejścia dadzą radę.
Wychodząc poza informacje organizacyjne do bardziej ogólnych
zastosowań metadanych - obecność interfejsów, metod czy pól jako
metadane - czemu nie. Refleksja czy narzędzia AOP obrabiające taki kod
niewiele różniłyby się od narzędzi obrabiających adnotacje. I w drugą
stronę - nawet jeśli to co zwracają metody "informacyjne" miałoby
generować się w czasie wykonania, to adnotacje plus sprytne narzędzie
AOP generujące kod także pozwoliłoby ten efekt osiągnąć, nawet
bardziej przejrzyście z punktu widzenia kodu "nieinformacyjnego".
Niereligijnie, czyli każde podejście może być w konkretnej sytuacji
lepsze...
W filozofii którą przytoczyłeś "adnotacja to metadana, nie wplywajaca
na dzialanie tej klasy (klasa nie jest nawet swiadoma tego), jest to
informacja dla innych czesci systemu" chodziło moim zdaniem o coś
innego - tzn. że bez dodatkowych narzędzi (kompilatora, AOP, VM i im
podobnych, tj. przetwarzających adnotacje) działanie (semantyka)
adnotowanego kodu nie ulega zmianie i tak rozumiem to sformułowanie
SYSTEM). Ale te dodatkowe narzędzia mogą zmienić semantykę tego co
jest adnotowane. Dodając do adnotacji narzędzia w rodzaju AOP czy
rozumiejące adnotacje VM (chyba nie ma takowych jeszcze), to nie ma
limitu jak bardzo. Nie ma też problemu, aby np. poprzez refleksję
adnotacje odczytać i od nich uzależnić logikę aplikacji.
> 0) wykluczam zewnetrzne XML, ja juz sie nie zmienie i literowki,
> zgodnosc typow musi sprawdzac kompilator.
To jest kwestia aktualnego stanu narzędzi. Technicznie nie ma
ograniczeń, aby takich sprawdzeń nie wykonywać...
> b) metody wirtualne zwl abstrakcyjne daja fajny przymus, adnotacje nie
> jest przymusowa.
To też może procesor adnotacji kontrolować. Jeśli byłby zintegrowany z
kompilatorem (lub narzędziami AOP) to także mógłby generować błędy/
ostrzeżenia kompilacji. Przykładem mogą byc standardowe adnotacje
@Deprecated i @Override.
> d) adnotacje maja typy podstawowe i wskazanie na klase, byc moze z
> przymusem dziedziczenia z hierarchii. Typy podstawowe nie sa szczytem
> szczescia, ale wystarczy. Wskazanie na klase jest kochane jak to polubic
> i dobrze uzyc.
Adnotacje w Java są IMHO na dzisiaj zbyt "wąskie". JSR-308 da sporo
więcej. Ja widziałbym je nawet na blokach kodu, pojedynczych
instrukcjach czy wyrażeniach (i jeszcze do tego ze wsparciem AOP aż do
poziomu JVM).
Np. z tego co widziałem (pobieżnie) w .NET są atrybuty (=adnotacje) na
poziomie instrukcji return, czy też w drugą stronę - na wyższym
poziomie, np. jednostek organizacyjnych kodu (assembly/module), co też
ma sens...
Moje trzy grosze...
Pozdrawiam,
Waldek Kot