The AOP idea of PHP

Story background: The problem: In the traditional OOP (object-oriented Programming: Object-oriented programming) idea, the application is generally decomposed into several objects, emphasizing high cohesion, weak coupling, thus increasing the modularity of the application, but in dealing with some problems, OOP is not flexible enough, for example, the application of many business logic in the beginning of the operation of "permission check", after the operation of "logging", if the code to deal with these operations directly into each module, then undoubtedly undermine the OOP "single responsibility" principle, The reusability of the module will be greatly reduced, when the traditional OOP design often adopts the strategy of adding the corresponding proxy layer to complete the functional requirements of the system, but this kind of processing obviously makes the whole system add a level of division, the complexity also increases, thus giving people too thick feeling. Solution: In order to deal with such problems, AOP (aspect-oriented programming: Aspect-oriented programming) came into being, assuming that the application is thought of as a stereoscopic structure, the blade of OOP is a longitudinal plunge system, The system is divided into many modules (such as: User module, article module, etc.), and the blade of AOP is the horizontal cut-in system, extracting the parts that each module may want to repeat (such as: Permission check, logging, etc.). Thus, AOP is an effective complement to OOP. As far as PHP is concerned, there is not a complete AOP built-in implementation, although there is runkit, but has been in the beta state of the PECL project, for a long time is not likely to be the default PHP settings. Is it that AOP was dashed in PHP? Of course not, because we have __get (), __set (), __call () and other magic methods, reasonable use of these methods can achieve some degree of "quasi-AOP" ability, is said to be quasi-AOP, because it is only in terms of implementation, it is somewhat farfetched to call it AOP, but from the effect of the view , and partially realize the role of AOP, although its implementation is not perfect, but for the general use is enough.

<?PHPclassbiz{ Public functionFoobar$num)     {          Print_r($num); Echo"\ nthe business logic do something"; }}classaop{Private $instance;  Public function__construct ($instance){          $this->instance =$instance; }      Public function__call ($method,$argument) {          if(!method_exists($this->instance,$method)) {               Throw New Exception(' Undefined method: '.$method); }          Echo"\ n permission Check";//--------------AOP          $callBack=Array($this->instance,$method); $return=Call_user_func($callBack,$argument); Echo"\ nthe log Record";//--------------AOP          return $return; }}classfactory{ Public Static functiongetbizinstance () {return NewAOP (NewBIZ ()); }}Try {     $obj= Factory::getbizinstance (); $obj->foobar (3);} Catch(Exception $e) {     Echo' Exception '.$e-getMessage ();}

/** * Summary: * The implementation of the whole idea is very simple, the key is that the client request object can not be directly instantiated, * but the use of factory method to return a Request object wrapper object, in the wrapper object using magic method to handle the permissions processing, log records and other public operations. * This is both a smart place and the most likely problem, because the client uses the object is not the object it imagines, * but a wrapped object, for example, the client through the Getbizinstance () method to get the object is biz, * But in fact it gets a biz wrapper object AOP, so that if the client does something like Get_class () and the object type related to the operation will go wrong, of course, in most cases, the client does not seem to be very likely to do similar operations */

Related: https://www.cnblogs.com/fps2tao/p/9263110.html

The AOP idea of PHP