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.