AOP (Aspect Orient Programming) wird als Ergänzung zur objektorientierten Programmierung häufig verwendet, um einige Dienste auf Systemebene mit übergreifenden Eigenschaften abzuwickeln, wie z. B. Transaktionsverwaltung, Sicherheitsprüfungen, Caching, Objektpoolverwaltung usw . Der Schlüssel zur AOP-Implementierung liegt im AOP-Proxy, der automatisch vom AOP-Framework erstellt wird. Statische Proxys und dynamische Proxys beziehen sich auf die Kompilierung mithilfe der vom AOP-Framework bereitgestellten Befehle Die AOP-Proxy-Klasse wird während der Kompilierungsphase auch als Erweiterung zur Kompilierungszeit bezeichnet, während der dynamische Proxy den dynamischen JDK-Proxy, CGLIB usw. verwendet, um die dynamische AOP-Proxy-Klasse zur Laufzeit „vorübergehend“ zu generieren wird auch Laufzeiterweiterung genannt.
Der Existenzwert von AOP
In der traditionellen OOP-Programmierung sind Objekte der Kern. Das gesamte Softwaresystem besteht aus einer Reihe voneinander abhängiger Objekte, und diese Objekte werden nacheinander in Klassen abstrahiert 1. Und ermöglicht die Verwendung der Klassenvererbung, um allgemeine bis spezifische Beziehungen zwischen Klassen zu verwalten. Da der Umfang der Software zunimmt und Anwendungen schrittweise aktualisiert werden, treten nach und nach einige Probleme auf, die mit OOP nur schwer zu lösen sind.
Wir können eine Reihe von Objekten mit bestimmten Attributen und Verhaltensweisen analysieren und abstrahieren und durch die Zusammenarbeit zwischen diesen Objekten eine vollständige Softwarefunktion bilden. Da Objekte vererbt werden können, können wir Attribute mit denselben Funktionen oder Eigenschaften in ein hierarchisches Klassenstruktursystem abstrahieren. Mit der kontinuierlichen Erweiterung der Softwarespezifikationen, der zunehmenden Zahl spezialisierter Arbeitsteilungen und der zunehmenden Zahl von OOP-Anwendungspraktiken wurden einige Probleme aufgedeckt, die OOP nicht gut lösen kann.
Angenommen, es gibt drei völlig ähnliche Codeteile im System. Diese Codes werden normalerweise durch „Kopieren“ und „Einfügen“ vervollständigt wie Abbildung 1 zeigt.
Abbildung 1. Software, die an mehreren Stellen denselben Code enthält
Beim Betrachten des schematischen Diagramms in Abbildung 1 haben einige Leser dies möglicherweise entdeckt Die Mängel von Dieser Ansatz: Wenn eines Tages das dunkle Codesegment in Abbildung 1 geändert werden muss, müssen Sie den Code dann an drei Stellen zur Änderung öffnen? Was würde passieren, wenn dieser Code nicht an drei Stellen, sondern an 100 oder sogar 1.000 Stellen enthalten wäre?
Um dieses Problem zu lösen, definieren wir normalerweise den dunklen Codeteil, wie in Abbildung 1 gezeigt, als Methode und rufen dann die Methode in den drei Codesegmenten auf. Auf diese Weise ist die Struktur des Softwaresystems in Abbildung 2 dargestellt.
Abbildung 2 Implementieren von Systemfunktionen durch Methodenaufrufe
Wenn Sie für das in Abbildung 2 gezeigte Softwaresystem den Code im dunklen Teil ändern müssen, Ändern Sie es einfach. Unabhängig davon, wie viele Stellen im gesamten System diese Methode aufrufen, muss das Programm diese Stellen nicht ändern. Nur die aufgerufene Methode kann geändert werden. Auf diese Weise wird die Komplexität der späteren Wartung verringert Software wird stark reduziert.
Für die in Abbildung 2 gezeigten Methoden 1, Methode 2 und Methode 3 müssen Sie immer noch explizit die dunkle Methode aufrufen, die die meisten Anwendungsszenarien lösen kann. Aber für einige speziellere Fälle: Die Anwendung erfordert, dass Methode 1, Methode 2 und Methode 3 vollständig von der dunklen Methode getrennt sind – Methode 1, Methode 2 und Methode 3 müssen die dunkle Methode nicht direkt aufrufen, also wie es lösen?
Da sich die Anforderungen an Softwaresysteme sehr häufig ändern, wurden in der frühen Systementwurfsmethode 1, Methode 2 und Methode 3 nur die Kerngeschäftsfunktionen implementiert. Nach einer gewissen Zeit müssen wir Methoden für Methode 1 und Methode 2 bereitstellen und Methode 3. Nach einiger Zeit schlug der Kunde Methode 1, Methode 2 und Methode 3 vor, die eine Überprüfung der Benutzerlegalität erforderte, und nur legitime Benutzer können diese Methoden nach einiger Zeit ausführen, schlug der Kunde Methode 1 vor , Methode 2 noch einmal, Methode 3 sollte nach einer Weile die Protokollierung hinzufügen, fragte der Kunde erneut ... Was sollten wir angesichts einer solchen Situation tun? In der Regel gibt es zwei Vorgehensweisen:
Die Anfrage des Kunden direkt auf Basis der Bedarfsspezifikation ablehnen.
Bedürfnisse annehmen und Kundenbedürfnisse erfüllen.
Der erste Ansatz ist offensichtlich nicht gut. Kunden sind Gott und wir sollten unser Bestes geben, um ihre Bedürfnisse zu erfüllen. Normalerweise wird der zweite Ansatz gewählt. Wie lässt sich das Problem lösen? Definieren wir zuerst eine neue Methode, ändern wir dann Methode 1, Methode 2 und Methode 3 und fügen neue aufzurufende Methoden hinzu? Der Arbeitsaufwand dafür ist nicht gering! Wir hoffen, eine spezielle Methode zu haben: Solange wir diese Methode definieren, besteht keine Notwendigkeit, sie in Methode 1, Methode 2 und Methode 3 explizit aufzurufen. Das System führt diese spezielle Methode „automatisch“ aus.
Die obige Idee klingt magisch und sogar ein wenig unrealistisch, aber sie ist tatsächlich vollständig realisierbar. Die Technologie zur Erfüllung dieser Anforderung ist AOP. AOP wird speziell zur Behandlung übergreifender Probleme verwendet, die in verschiedenen Modulen (verschiedenen Methoden) im System verteilt sind. In Java EE-Anwendungen wird AOP häufig zur Abwicklung einiger übergreifender Dienste auf Systemebene verwendet, wie z. B. Transaktionsverwaltung und Sicherheitsinspektionen ., Caching, Objektpoolverwaltung usw. ist AOP zu einer sehr verbreiteten Lösung geworden.
Spring AOP-Prinzipanalyse
Wie Sie aus der vorherigen Einführung wissen können: Der AOP-Proxy ist tatsächlich ein vom AOP-Framework dynamisch generiertes Objekt, das als Zielobjekt verwendet werden kann. Der AOP-Proxy enthält alle Methoden des Zielobjekts, aber die Methoden im AOP-Proxy unterscheiden sich von den Methoden des Zielobjekts: AOP-Methoden fügen eine erweiterte Verarbeitung an bestimmten Einstiegspunkten hinzu und rufen die Methoden des Zielobjekts zurück.
Die im AOP-Proxy enthaltenen Methoden und das Methodendiagramm des Zielobjekts sind in Abbildung 3 dargestellt.
Abbildung 3. AOP-Proxy-Methoden und Zielobjektmethoden
Der AOP-Proxy von Spring wird vom IoC-Container von Spring generiert und verwaltet, und seine Abhängigkeiten werden ebenfalls verwaltet durch den IoC-Container. Daher können AOP-Proxys direkt auf andere Bean-Instanzen im Container abzielen, eine Beziehung, die durch die Abhängigkeitsinjektion des IoC-Containers bereitgestellt wird.
Bei der AOP-Programmierung gibt es nur drei Teile, die die Teilnahme von Programmierern erfordern:
Definieren Sie gemeinsame Geschäftskomponenten.
Definieren Sie Einstiegspunkte. Ein Einstiegspunkt kann mehrere Geschäftskomponenten umfassen.
Definieren Sie die erweiterte Verarbeitung, bei der es sich um eine Verarbeitungsaktion handelt, die in das AOP-Framework für gewöhnliche Geschäftskomponenten eingebunden ist.
Der erste Teil der oben genannten 3 Teile ist der häufigste und bedarf keiner weiteren Erklärung. Dann liegt der Schlüssel zur AOP-Programmierung darin, Einstiegspunkte zu definieren und die Erweiterungsverarbeitung zu definieren. Sobald der entsprechende Einstiegspunkt und die erweiterte Verarbeitung definiert sind, generiert das AOP-Framework automatisch einen AOP-Proxy, und die Methode des AOP-Proxys hat ungefähr die folgende Formel:
Methode des Proxy-Objekts = Erweiterte Verarbeitung + Methode des Proxy-Objekts
In der obigen Geschäftsdefinition ist es nicht schwer zu erkennen, dass das Implementierungsprinzip von Spring AOP tatsächlich sehr einfach ist: Das AOP-Framework ist für die dynamische Generierung der AOP-Proxy-Klasse und der Methoden verantwortlich Diese Proxy-Klasse besteht aus Advice- und Callback-Zielobjektmethoden.
Für die in der zuvor erwähnten Abbildung 2 gezeigte Software-Aufrufstruktur: Wenn Methode 1, Methode 2, Methode 3 ... alle eine Methode mit „übergreifenden“ Eigenschaften aufrufen müssen, ist der traditionelle Ansatz oben Es ist für den Programmierer erforderlich, Methode 1, Methode 2, Methode 3 ... manuell zu ändern und diese „übergreifende“ Methode über den Code aufzurufen. Dieser Ansatz weist jedoch eine schlechte Skalierbarkeit auf, da der Code jedes Mal geändert werden muss.
So entstand das AOP-Framework. Das AOP-Framework kann „dynamisch“ eine neue Proxy-Klasse generieren, und diese Proxy-Klasse enthält Methode 1, Methode 2, Methode 3 ... und fügt auch die Möglichkeit hinzu, diese A aufzurufen „Cross-Cutting“-Methode – dieser Aufruf wird jedoch von der vom AOP-Framework automatisch generierten Proxy-Klasse übernommen und weist daher eine hervorragende Skalierbarkeit auf. Programmierer müssen den Code von Methode 1, Methode 2 und Methode 3 nicht manuell ändern. Programmierer müssen nur den Einstiegspunkt definieren – die vom AOP-Framework generierte AOP-Proxy-Klasse enthält neue Methode 1, Zugriffsmethode 2 und Methode 3 , und Das AOP-Framework entscheidet basierend auf dem Einstiegspunkt, ob Methoden mit „übergreifenden“ Eigenschaften in Methode 1, Methode 2 und Methode 3 zurückgerufen werden.
Kurz gesagt: Das Geheimnis des AOP-Prinzips besteht darin, dynamisch eine Proxy-Klasse zu generieren, die den Aufruf in Abbildung 2 implementiert – dieser Aufruf erfordert keine Änderung des Codes durch den Programmierer.
Zusammenfassung
AOP wird häufig zur Verarbeitung einiger Dienste auf Systemebene mit übergreifenden Eigenschaften verwendet. Das Aufkommen von AOP ist eine gute Ergänzung zu OOP, die es Entwicklern ermöglicht, Dienste mit übergreifenden Eigenschaften eleganter zu handhaben. Unabhängig von der Art der AOP-Implementierung, ob AspectJ oder Spring AOP, müssen alle dynamisch eine AOP-Proxy-Klasse generieren. Der einzige Unterschied besteht im Zeitpunkt der Generierung der AOP-Proxy-Klasse: AspectJ generiert die AOP-Proxy-Klasse zur Kompilierungszeit. Daher ist die Leistung besser, es ist jedoch die Verwendung eines bestimmten Compilers für die Verarbeitung erforderlich. Spring AOP verwendet die Laufzeit, um AOP-Proxy-Klassen zu generieren, sodass für die Verarbeitung kein bestimmter Compiler erforderlich ist. Da Spring AOP bei jedem Lauf einen AOP-Proxy generieren muss, ist die Leistung etwas schlechter.
Weitere Artikel zum Verständnis von SpringAOP finden Sie auf der chinesischen PHP-Website!
