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



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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.

do góry

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:

-zaloguj wywołania każdej metody w JAR, która bierze jako
jeden z paramterów MyInterestingObject i rzuca BusinessException.
Oczywiście w logach są parametry i wartość zwracan lub wyjątek

- po każdej metodzie na obiekcie A i po new sprawdź, czy w obiekcie
są zachowane inwarianty

- sprawdź, czy pole obiekt.x jest tą samą instancją czy przekazywany
parametr do metody innyObiekt.frob(x), poczas gdy obiekt.y się nie
zmienił

Mniej dosłownie, ogólnie jest to pewien wzorzec projektowy, który
pozwala obłożyć każdą operację przed i po jakimś kodem. Może to
być pełen zestaw
- autoryzacja
- cache
- powiązanie ze środowiskiem, kontekst całej aplikacji
- powiązanie ze środowiskiem, kontekst procesu biznesowego
- transakcyjność
- logowanie
- audyt
- cokowiek jeszcze sobie wymyślisz

Nie odnosi się to tylko do metod, ale też dostępu do zmiennych.

Edek

do góry

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 :-?




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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:
>
> -zaloguj wywołania każdej metody w JAR, która bierze jako
> jeden z paramterĂłw MyInterestingObject i rzuca BusinessException.
> Oczywiście w logach są parametry i wartość zwracan lub wyjątek
>
> - po kaĹźdej metodzie na obiekcie A i po new sprawdĹş, czy w obiekcie
> są zachowane inwarianty
>
> - sprawdź, czy pole obiekt.x jest tą samą instancją czy przekazywany
> parametr do metody innyObiekt.frob(x), poczas gdy obiekt.y się nie
> zmienił
>
> Mniej dosłownie, ogólnie jest to pewien wzorzec projektowy, który
> pozwala obłożyć każdą operację przed i po jakimś kodem. Może to
> być pełen zestaw
> - autoryzacja
> - cache
> - powiązanie ze środowiskiem, kontekst całej aplikacji
> - powiązanie ze środowiskiem, kontekst procesu biznesowego
> - transakcyjność
> - logowanie
> - audyt
> - cokowiek jeszcze sobie wymyślisz
>
> Nie odnosi się to tylko do metod, ale też dostępu do zmiennych.
>

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)




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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.

Edek

do góry

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.

do góry

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' )

nie bardzo jednak kojarze w danym momencie inne zastosowania
niz te z logiem, np w jakim sensie cache lub inne?





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

(moze zreszta nawet daloby sie podzielic tak rozumiane
aspekty na odzielne procesory, to ew tez mogloby byc
cos ciekawego)

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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)





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry