Programowanie aspektowe

Programowanie aspektowe (aspect-oriented programming, AOP) to paradygmat tworzenia programów komputerowych wspomagający separację zagadnień i rozdzielenie programu na części w jak największym stopniu niezwiązane funkcjonalnie.

Autorem koncepcji jest Gregor Kiczales^[1] i jego zespół w firmie Xerox PARC. Stworzyli oni również pierwsze i wciąż najbardziej popularne aspektowe rozszerzenie dla języka Java - AspectJ.

Microsoft Transaction Server jest uważany za pierwsze znaczące zastosowanie programowania aspektowego (AOP), a następnie Enterprise JavaBeans^[2][3].

Przyczyna zapotrzebowania

Każde realizowane zagadnienie pociąga za sobą w praktyce potrzebę realizacji zagadnień pobocznych. Na przykład program przelewający pieniądze na kontach bankowych realizuje nie tylko swój główny cel (tj. pomniejszenie zawartości jednego konta i powiększenie zawartości drugiego), ale równocześnie z nim również zagadnienia logowania, bezpieczeństwa, spójności transakcyjnej, autoryzacji, synchronizacji wielowątkowej i wiele innych. Jest to zjawisko normalne, wynikające ze złożoności wymagań klienta. Zagadnienia te są w dużym stopniu rozłączne pomiędzy sobą pod względem funkcjonalnym. Aby je zrealizować, programista musi poprzeplatać ich implementacje (tzw. warkocz), co czyni kod mniej czytelnym, bardziej podatnym na błędy, trudniejszym w modyfikacji^[4].

Programowanie aspektowe zapobiega tym negatywnym skutkom oddzielając fizycznie kod każdego zagadnienia poprzez umieszczenie ich w oddzielnych aspektach i logiczne zdefiniowanie punktów interakcji pomiędzy nimi.

Krytyka

Najbardziej podstawowym zarzutem wobec programowania aspektowego (AOP) jest to, że przepływ sterowania staje się nieczytelny. Uważa się, że jest to nie tylko gorsze niż powszechnie krytykowana instrukcja GOTO, ale również bliskie analogii do żartobliwej instrukcji COME FROM^[5]. Fundamentalna dla wielu definicji AOP cecha "nieświadomości" aplikacji (kod nie zawiera żadnych wskazówek, że zastosowane zostanie doradztwo, które określane jest zamiast tego w punktach przecięcia – pointcut) oznacza, że doradztwo pozostaje niewidoczne, w przeciwieństwie do jawnego wywołania metody. Na przykład można to porównać do programu wykorzystującego instrukcję COME FROM^[5].