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.

do góry

W dniu 2012-05-09 15:57, f...@g...SKASUJ-TO.pl pisze:
> zażółcony<r...@c...pl> napisał(a):
>
>> W dniu 2012-05-09 12:33, f...@g...SKASUJ-TO.pl pisze:
>>> zażółcony<r...@c...pl> napisał(a):
>>>
>>>> W dniu 2012-05-08 21:54, prof fir pisze:
>>>>> 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
>>>>
>>>> Elementy programowania/myślenia aspektowego pojawiają się
>>>> wszędzie, ja akurat obserwuję to na przykładzie
>>>> J2EE - tylko często się tego nie nazywa po imieniu
>>>> i często jest to zapisane w sposób nieefektywny (bo za pomocą
>>>> takiego języka jak Java). Wiele wzorców projektowych
>>>> ma w sobie coś z idei programowania aspektowego.
>>>>
>>>> Jakiś prosty przykład ...
>>>>
>>>> Masz typową funkcję 'biznesową', która coś wyciąga
>>>> z bazy danych, oblicza i do bazy zapisuje. Jak baza
>>>> danych - to musi być jakieś łączenie z tą bazą a potem
>>>> transakcja. Pominę samo łączenie, zostanę przy transakcji.
>>>> Twoja funkcja wyglada wtedy tak:
>>>>
>>>> void MyFun() {
>>>> BeginTrans()
>>>> x=SELECT Z BAZY
>>>> x = x * y * COSTAM
>>>> UPDATE BAZY (x)
>>>> CommitTrans()
>>>> }
>>>>
>>>> W tej postaci funkcja ma jeszcze sporą 'niedoróbkę', a
>>>> mianowicie - brak obsługi błędów. Dodajmy więc coś podstawowego:
>>>>
>>>> void MyFun() {
>>>> BeginTrans()
>>>> try {
>>>> x=SELECT Z BAZY
>>>> x = x * y * COSTAM
>>>> UPDATE BAZY (x)
>>>> CommitTrans()
>>>> } catch (ex) {
>>>> log.err(ex)
>>>> RollbackTrans()
>>>> }
>>>> }
>>>>
>>>> Czy powyższy kod jest zły ? Dodać komentarze i będzie OK. Nie da się
>>>> tego zrobić 'prościej'.
>>>> (przy okazji będziesz miał odpowiedź na swoje pytanie w innym wątku,
>>>> co to oznacza wprowadzić abstrakcję).
>>>>
>>>> A teraz sobie wyobraź, że masz 10 programistów i tysiące takich
>>>> funkcji. Każdy z programistów robi copy paste tych beginów, endów,
>>>> try-catchów, każdy coś tam zmieni (np. niektórzy OpenTrans() będę robić
>>>> po try, a nie przed, jak w w.w. przykładzie.
>>>> Generalnie - kod nie jest zbyt czytelny. Wynika to m.in. z tego, że
>>>> w jednej funkcji łączy dwa aspekty: aspekt biznesowy i aspekt techniczny
>>>> związany z zarządzaniem transakcjami.
>>>> Na marginesie: Można troszeczkę ograniczyć ten techniczny aspekt
>>>> wprowadzając obiekty do zarządzanai transakcjami (TransactionScope) i
>>>> korzystając z wzorca RIAA, ale w jezyku takim jak Java akurat nic to nie
>>>> da, bo obiekty nie mają destruktorów.
>>>>
>>>> Więc wydzielamy aspekt transakcyjności na zewnątrz.
>>>> W bardzo dużym, przykładowym uproszczeniu, będziemy teraz mieć
>>>> dwa współpracujące obiekty: manager transakcji oraz funkcję biznesową:
>>>>
>>>> class MyFunBiz {
>>>> public execute() {
>>>> x=SELECT Z BAZY
>>>> x = x * y * COSTAM
>>>> UPDATE BAZY (x)
>>>> }
>>>> }
>>>>
>>>> Powyżej zero kodu transakcyjnego, który jest teraz tu:
>>>>
>>>> class ManagerFunkcjiBiznesowych {
>>>> public execute(MyFunBiz funBiz) {
>>>> BeginTrans()
>>>> try {
>>>> funBiz.execute()<--- Tu wywołujesz kod biznesowy
>>>> CommitTrans()
>>>> } catch (ex) {
>>>> log.err(ex)
>>>> RollbackTrans()
>>>> }
>>>> }
>>>> }
>>>>
>>>> Wywołanie naszej funkcji polega teraz na utworzeniu obiektu
>>>> i przekazaniu go do managera funkcji/transakcji, który
>>>> 'otacza' ją transakcją bazodanową.
>>>>
>>>> fun = MyFunBiz()
>>>> ManagerFunkcjiBiznesowych.execute(fun)
>>>>
>>>> Programowanie aspektowe polega właśnie na takim 'otaczaniu',
>>>> jak w cebuli. W środku masz zasadniczą funkcję biznesową
>>>> i Twoich 10 programistów zajmuje się dostarczaniem tego
>>>> środka (zobacz o ile jest to teraz czytelniejsze i zwięźlejsze),
>>>> a potem sami lub automatycznie jest to 'otaczane'
>>>> kolejnymi sukienkami - kolejnym aspektami/kontekstami (u nas jest
>>>> jeden - kontekst transakcji bazodanowej).
>>>> Programowanie aspektowe pozwala to robić w bardzo efektywnym
>>>> zapisie, natomiast w języku takim jak Java trzeba tworzyć
>>>> obiekty, interfejsy, klasy anonimowe, jest zamieszanie z przekazywaniem
>>>> parametrów itp itd (co ja w przykładach w dużej części pominąłem).
>>>>
>>>> Masz też powyżej przykład utworzenia abstrakcji - abstrakcją jest
>>>> tu np. pojęcie funkcji biznesowej, w której zajmujemy się wyłącznie
>>>> biznesem, a transakcje mamy już zapewnione 'z zewnątrz.
>>>
>>> dosyc ciekawe, (a jakos nigdy nie slyszalem nic ntt),
>>> nawet ten kod w miare, tx za odp
>>> z tym ze nie rozumiem tego kawalka
>>>
>>>> public execute() {
>>> /**/
>>> }
>>>
>>> to chyba skrot, czy tez jakies jezyk umozliwia takie opakowywanie
>>> / przekazywanie blokow kodu do srodka funkcji :-?
>>
>> to deklaracja metody w klasie ...
>>
>> w konwencji Java:
>>
>> class X {
>> ...
>> public void execute(){
>> ...
>> }
>> }
>>
>> W praktyce obecnych realizacji pojawiłby się tu albo
>> interfejs, który dopiero byłby implementowany w konkretnej klasie,
>> albo coraz częściej, zamiast opakowywanai wszystkiego interfejsami
>> markuje się metody adnotacjami, a mechanizmy uczy ich sprawnego
>> rozpoznawania. Ale to już szczegóły realizacji technicznej.
>
> ok, nie zauwazylem ze to nie funkcja tylko 'k..sa' (wole nie
> uzywac tego dla mnie wyraznie niecenzuralnego slowa) i przez
> to myslem ze to nie definicja tylko jakies wywolanie z zapodanym
> blokiem (kiedys zreszta bedzie trzeba przemyslec czy takie
> bloki ad hoc nie przydalyby sie moze na cos)

Takie bloki 'at hoc' to w przybliżeni w Javie realizuje
się za pomocą klas anonimowych, a dla większej zwięzłości
zapisu od lat już rozważa się wprowadzenie tzw. closures:
http://tronicek.blogspot.com/2007/12/closures-closur
e-is-form-of-anonymous_28.html
Aczkolwiek warto wiedzieć, ze w językach takich jak Java
wszystko, co nie jest zupełnie proste - jest obiektem
- a więc gdzieś tam pod spodem i tak jest generowana klasa
i tworzona jej instancja - a ten obiekt jest przekazywany
jako argument do jakiejś funkcji(metody) innego obiektu.
W sumie to imo ułatwia zrozumienie, jak to działa i
jakie są ograniczenia.

do góry

> coraz częściej, zamiast opakowywanai wszystkiego interfejsami
> markuje się metody adnotacjami, a mechanizmy uczy ich sprawnego
> rozpoznawania.

Chodzi Ci o "atrybuty" nadawane klasom, metodom...?

--
Mateusz Bogusz

do góry

On 09/05/2012 15:13, zażółcony wrote:
>
> Takie bloki 'at hoc' to w przybliżeni w Javie realizuje
> się za pomocą klas anonimowych, a dla większej zwięzłości
> zapisu od lat już rozważa się wprowadzenie tzw. closures:
> http://tronicek.blogspot.com/2007/12/closures-closur
e-is-form-of-anonymous_28.html

Ino klasy anonimowe nie mają tego, co jest jakby dość istotne w
"closures" (zwanych gdzieniegdzie lambdami), czyli owego "lexical
closure" - nie można się w nich odwoływać do symboli zdefiniowanych w
zawierającym zakresie - co dość poważnie ogranicza sensowne ich użycie.

do góry