Dieser Artikel stellt hauptsächlich die Analyse des AOP-Denkens vor, die einen gewissen Referenzwert hat. Jetzt kann ich ihn mit allen teilen. Freunde in Not können darauf zurückgreifen.
Hintergrund der Geschichte:
Frage :
Im traditionellen OOP-Denken (objektorientierte Programmierung) werden Anwendungen im Allgemeinen in mehrere Objekte zerlegt, wobei ein hoher Zusammenhalt und eine schwache Kopplung im Vordergrund stehen, wodurch die Anwendungsmodule verbessert werden. Bei der Behandlung bestimmter Probleme ist OOP jedoch nicht der Fall
Beispielsweise müssen viele Geschäftslogiken in der Anwendung eine „Berechtigungsprüfung“ zu Beginn des Vorgangs und eine „Berechtigungsprüfung“ nach dem Vorgang durchführen Wenn es direkt zu jedem Modul hinzugefügt wird, wird es zweifellos das Prinzip der „einzelnen Verantwortung“ von OOP zerstören und die Wiederverwendbarkeit des Moduls wird stark eingeschränkt.
Zu diesem Zeitpunkt wird die traditionelle Strategie häufig im OOP-Design angewendet Das Hinzufügen der entsprechenden Proxy-Schicht zur Vervollständigung der Funktionsanforderungen des Systems führt jedoch offensichtlich zu einer Aufteilung des Gesamtsystems, und die Komplexität nimmt entsprechend zu, was den Menschen ein übermäßig schweres Gefühl vermittelt.
Lösung:
Um solche Probleme zu lösen, entstand die Idee von AOP (Aspektorientierte Programmierung). Angenommen, die Anwendung wird als dreidimensional betrachtet Struktur: Die scharfe Kante von OOP besteht darin, vertikal in das System einzuschneiden und das System in viele Module zu unterteilen (z. B. Benutzermodule, Artikelmodule usw.), während die scharfe Kante von AOP darin besteht, horizontal in das System einzuschneiden und es zu extrahieren Teile, die möglicherweise wiederholte Vorgänge in jedem Modul erfordern (z. B. Berechtigungsprüfung, Protokollierung usw.). Es zeigt sich, dass AOP eine wirksame Ergänzung zu OOP darstellt.
Was das aktuelle PHP betrifft, gibt es noch keine vollständige integrierte Implementierung von AOP. Obwohl RunKit erschienen ist, befindet es sich schätzungsweise immer im BETA-Status Es ist unwahrscheinlich, dass PHP auf lange Sicht zu den Standardeinstellungen wird. Bedeutet das, dass AOP in PHP defekt ist? Natürlich nicht, denn wir haben __get(), __set(), __call() und andere magische Methoden, die für uns einen gewissen Grad an „Quasi-AOP“-Fähigkeiten erreichen können Sein Quasi-AOP liegt daran, dass es aus Sicht der Implementierung etwas weit hergeholt ist, es AOP zu nennen, aber aus Sicht der Wirkung erkennt es teilweise die Rolle von AOP. Obwohl seine Implementierung nicht perfekt ist ist für den allgemeinen Gebrauch ausreichend.
<?php class BIZ { public function foobar($num) { print_r($num); echo "\n业务逻辑 do something"; } } class AOP{ private $instance; public function __construct($instance){ $this->instance = $instance; } public function __call($method,$argument) { if (!method_exists($this->instance, $method)) { throw new Exception('未定义的方法:' . $method); } echo "\n权限检查"; //--------------AOP $callBack = array($this->instance,$method); $return = call_user_func($callBack,$argument); echo "\n日志记录"; //--------------AOP return $return; } } class Factory { public static function getBizInstance() { return new AOP(new BIZ()); } } try { $obj = Factory::getBizInstance(); $obj->foobar(3); } catch (Exception $e) { echo 'Exception '.$e->getMessage(); }
Das Obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, er wird für das Studium aller hilfreich sein. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website.
Verwandte Empfehlungen:
Grundlagen der Funktionsweise von PHP
So generieren Sie Kurzlinks in PHP
Das obige ist der detaillierte Inhalt vonAnalyse des AOP-Denkens von PHP. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!