Co to jest programowanie aspektowe?

Rozumiem programowanie obiektowe i piszę programy OO od dłuższego czasu. Wydaje się, że ludzie mówią o programowaniu aspektowym, ale tak naprawdę nigdy nie nauczyłem się, co to jest i jak go używać. Jaki jest podstawowy paradygmat?

To pytanie jest powiązane, ale nie do końca zadane:

Programowanie aspektowe a programowanie obiektowe

AOP rozwiązuje problem problemów przekrojowych , którym byłby każdy rodzaj kodu, który jest powtarzany różnymi metodami i zwykle nie można go całkowicie przebudować na własny moduł, na przykład przy logowaniu lub weryfikacji. Dzięki AOP możesz pozostawić te elementy poza głównym kodem i zdefiniować je pionowo:

function mainProgram()
{ 
   var x =  foo();
   doSomethingWith(x);
   return x;
}

aspect logging
{ 
    before (mainProgram is called):
    { 
       log.Write("entering mainProgram");
    }

    after (mainProgram is called):
    { 
       log.Write(  "exiting mainProgram with return value of "
                  + mainProgram.returnValue);
    }
 } 

aspect verification
{ 
    before (doSomethingWith is called):
    { 
       if (doSomethingWith.arguments[0] == null) 
       { 
          throw NullArgumentException();
       }

       if (!doSomethingWith.caller.isAuthenticated)
       { 
          throw Securityexception();
       }
    }
 }

Następnie do kompilacji kodu użyto tkacza aspektów :

function mainProgram()
{ 
   log.Write("entering mainProgram");

   var x = foo();   

   if (x == null) throw NullArgumentException();
   if (!mainProgramIsAuthenticated()) throw Securityexception();
   doSomethingWith(x);   

   log.Write("exiting mainProgram with return value of "+ x);
   return x;
} 

Niestety, wydaje się zaskakująco trudne uczynienie AOP naprawdę użytecznym w normalnej organizacji średniej wielkości. (Wsparcie redaktora, poczucie kontroli, fakt, że zaczynasz od nie tak ważnych rzeczy prowadzących do zepsucia kodu, ludzi wracających do domu do swoich rodzin itp.)

Nadzieję pokładam w programowaniu zorientowanym kompozytowo , które jest coraz bardziej realistyczne. Łączy się z wieloma popularnymi pomysłami i daje ci coś naprawdę fajnego.

Spójrz na nadchodzące wdrożenie tutaj: qi4j.org/

PS. Właściwie uważam, że jedną z piękności z AOP jest również pięta achillesowa: nieinwazyjna, pozwalająca ludziom zignorować ją, jeśli mogą, więc będzie to traktowane jako problem drugorzędny w większości organizacji.

Skopiowano z duplikatu kompletności (Einstein):

Klasyczne przykłady to bezpieczeństwo i logowanie. Zamiast pisać kod w aplikacji, aby rejestrować występowanie x lub sprawdzać obiekt z pod kątem kontroli bezpieczeństwa, istnieje urządzenie językowe „poza pasmem” normalnego kodu, które może systematycznie wprowadzać zabezpieczenia lub logować się do procedur, które nie mają ich natywnie w taki sposób, że nawet jeśli twój kod go nie dostarcza - jest załatwiony.

Bardziej konkretnym przykładem jest system operacyjny zapewniający kontrolę dostępu do pliku. Program nie musi sprawdzać ograniczeń dostępu, ponieważ system bazowy to działa.

Jeśli uważasz, że potrzebujesz AOP z mojego doświadczenia, tak naprawdę naprawdę musisz poświęcić więcej czasu i wysiłku na odpowiednie zarządzanie metadanymi w swoim systemie, ze szczególnym naciskiem na dobrze przemyślane projektowanie strukturalne / systemów.

Skopiowano z Spring in Action

AOP jest często definiowany jako technika, która promuje rozdzielenie problemów w systemie oprogramowania. Systemy składają się z kilku komponentów, z których każdy odpowiada za określoną funkcjonalność. Ale często te komponenty mają także dodatkowe obowiązki wykraczające poza ich podstawową funkcjonalność. Usługi systemowe, takie jak rejestrowanie, zarządzanie transakcjami i bezpieczeństwo, często trafiają do komponentów, których podstawowymi obowiązkami jest coś innego. Te usługi systemowe są powszechnie nazywane problemami przekrojowymi, ponieważ mają tendencję do przecinania wielu komponentów w systemie.

Skopiowano z duplikatu kompletności (Buzzer):

Atrybuty klas i metod w .NET są formą programowania zorientowanego na aspekty. Dekorujesz swoje klasy / metody atrybutami. Za kulisami dodaje to kod do twojej klasy / metody, która wykonuje określone funkcje atrybutu. Na przykład oznaczenie klasy możliwej do serializacji umożliwia jej automatyczne serializowanie w celu przechowywania lub przesyłania do innego systemu. Inne atrybuty mogą oznaczać niektóre właściwości jako niepodlegające serializacji i zostaną one automatycznie pominięte w serializowanym obiekcie. Serializacja jest aspektem, zaimplementowanym przez inny kod w systemie i zastosowanym do twojej klasy przez zastosowanie atrybutu „konfiguracja” (dekoracja).

AOP można wykorzystać do wykonywania działań niezwiązanych z logiką biznesową aplikacji, takich jak rejestrowanie, buforowanie itp. Działania te można umieścić w osobnej części aplikacji, a następnie ponownie wykorzystać w aplikacji. Zazwyczaj istnieją dwa sposoby osiągnięcia tego celu. Automatyczne wstrzykiwanie kodu przez preprocesor przed / po metodzie lub dołączanie klas proxy, które przechwytują wywołanie metody, a następnie mogą wykonywać czynności przed / po wywołaniu metody.

Oto przykład w .Net. Używa klas proxy do przechwytywania wywołań metod i wykonywania kodu przed wywołaniami metod saif.

Programowanie zorientowane na aspekty (AOP) w .NET Core i C # przy użyciu AutoFac i DynamicProxy

Istnieje przykład AOP, wykorzystano jako przykład AOP wiosenny. Przykład jest dość łatwy do zrozumienia.

Struktura Spring AOP (programowanie zorientowane na aspekty) służy do modularyzacji problemów przekrojowych w aspektach. Mówiąc prościej, jest to tylko przechwytywacz do przechwytywania niektórych procesów, na przykład, gdy metoda jest wykonywana, Spring AOP może przejąć metodę wykonywania i dodać dodatkową funkcjonalność przed lub po wykonaniu metody.

Odniesienie: http://www.mkyong.com/spring/spring-aop-examples-advice/

AOP to sposób na lepszą modularyzację aplikacji pod kątem funkcjonalności obejmującej wiele granic. AOP to kolejny sposób na enkapsulację tych funkcji i podążanie za pojedynczą odpowiedzialnością poprzez przeniesienie tych przekrojowych problemów (rejestrowanie, obsługa błędów itp.) Poza główne komponenty aplikacji. Przy właściwym stosowaniu AOP może z czasem prowadzić do wyższych poziomów łatwości konserwacji i rozszerzalności aplikacji.