W dniu 2012-05-09 15:48, f...@g...SKASUJ-TO.pl pisze:
> Edek Pienkowski<e...@g...com> napisał(a):
>
>> Dnia Wed, 09 May 2012 10:39:42 +0000, napisal:
>>
>>> Edek Pienkowski<e...@g...com> napisał(a):
>>>
>>>> Dnia Tue, 08 May 2012 19:54:29 +0000, prof fir napisal:
>>>>
>>>>> zasadniczo pierwszy raz o tym slysze, spostrzezenie
>>>>> w polskiej wiki wydaje sie sensowne, ale czy ktos tego
>>>>> uzywal, czy da sie to jakos zrobic i jak to wyglada
>>>>
>>>> Tak dosłownie, to w Javie masz AspectJ. Pozwala za pomocą
>>>> 20 linijek kodu zrobić takie rzeczy:
>>>>
>> [...]
>>>>
>>>
>>> w sumie to dosyc ciekawa rzecz, przynajmniej jako pojecie
>>> bo pewnie moze byc trudno wyaspektowywac pewne kawalki w
>>> praktyce (np. log musi miec cala mase lokalnych 'dowiazan'
>>> choc tez mi sie nie podoba ze brudzi kod)
>>
>> Akurat jest dokładnie odwrotnie: aspekty są poza głównym
>> kodem, pozostawiając samą treść działania wolną (przynajmniej
>> wizualnie) od aspektĂłw.
>>
>> Czasami to jest niekorzystne, trzeba zdawać sobie sprawę,
>> że istnieje kod modyfikujący zachowanie, którego jawnie
>> nie widać. Coś za coś, ogólnie daje to więcej niż jest
>> z tym problemĂłw.
>>
>
> da sie w kazdym razie pomyslec, np jako wywolywanie np
> ukrytych metot atBegin() czy atEnd() czy np aspectsResolve()
> albo cos dla oznaczunych akcji (np funkcji) w normalnym kodzie -
> takie 'handlery' musialyby miec mozliwosc zidentyfikowania funkcji spod
> ktorej zostaly wywolane i np dostepu do jej zmiennych
> lokalnych - co technicznie da sie zrobic, nie mowie ze to
> koniecznie dobry pomysl ale koncepcja ciekawa (np odwalenie
> milionow wywolan do loga do odzielnego 'centrum' )

Niekoniecznie zaraz muszą znać parametry - zobacz przykład
z transakcją - czy funkcje zaczynające i kończące transakcję
bazodanową muszą znać parametry biznesowe przekazywane
do środka tej funkcji ?

> nie bardzo jednak kojarze w danym momencie inne zastosowania
> niz te z logiem, np w jakim sensie cache lub inne?
No miałeś przykład - otwarcie i zamkniecie transakcji.
Inne: sprawdzenie, czy użytkownik ma uprawnienia do korzystania
z danej funkcji - zamiast trzaskać ify w tej funkcji
wyciągające
1. dane z sesji użytkownika identyfikujące
2. dane z jakiegoś zarządcy uprawnień, który wie, kto co może
dodajesz aspekt - atBegin (jak to nazwałeś) do każdej funkcji
systemu, który to robi i jak nie ma uprawnień - rzuca wyjątek.
W funkcji znów nie masz ani kawałka kodu, który by się tym musiał
przejmować

Kolejny przykład: zapewnianie wyłączności dostępu. Chcesz mieć
pewność, że dwóch użytkowników pracujących na dwóch różnych
stanowiskach pracy nie ma jednocześnie dostępu do tych samych
danych osobowych klienta (żeby jeden drugiemu ich nie nadpisywał
a za to, by był świadomy, że ktoś inny właśnie w nich grzebie).
Wiec znów: dodajesz atBegin, który zakłada blokadę(semafor
lub jakkolwiek to będzie technicznie zrealizowane) na zasobie,
i atEnd, który ją zdejmuje. jak atBegin nie daje rady, to wyjatek
lub inny sposób, który w efekcie końcowym wyświetli userowi
okienko "Poczekaj, dane klienta są obecnie przetwarzane na stanowisku
XXX". I znów - funkcja, która przetwarza dane nie ma żadnych
ifów itp, w ogóle się tym nie zajmuje.