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.