PHP uses Magic method to realize quasi-AOP

PHP uses Magic method to realize quasi-AOP

In traditional OOP (object-oriented Programming: Object-oriented programming), the application is generally decomposed into several objects, emphasizing high cohesion and weak coupling, thus increasing the modularity of the application, but when dealing with certain 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. It is in order to deal with this problem, AOP (aspect-oriented programming: Aspect-oriented programming) thought came into being, assuming the application as a stereoscopic structure, the blade of OOP is a longitudinal cut-off system, the system is divided into a number of modules (such as: User modules, text The blade of the AOP is the horizontal cut-in system, extracting the parts that each module may want to repeat (for example, permission checking, logging, and so on). 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. Especially since PHP4.3.0, these magic methods have become the default built-in implementations of PHP, eliminating PHP4/5 compatibility concerns, and there's no reason to not use them. Here to illustrate is PHP5 on the implementation of these magic methods are slightly different, the following examples we illustrate:

<?php
A business logic class in an application
Class BIZ
{
Public Function Foobar ()
{
Echo ' business logic <br/> ';
}
}
Wrapper classes for business logic classes
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 (' Undefined method: '. $method);
}
echo ' permission check <br/> ';
$callBack = Array ($this->instance, $method);
$return = Call_user_func_array ($callBack, $argument);
echo ' log record <br/> ';
return $return;
}
}
Factory method
Class Factory
{
Public Function getbizinstance ()
{
return new AOP (new BIZ ());
}
}
Client Invoke Demo
Header ("content-type:text/html; CHARSET=GBK ");
Try
{
$obj = Factory::getbizinstance ();
$obj->foobar ();
}
catch (Exception $e)
{
Echo ' caught exception: ', $e->getmessage ();
}
?>

Screen display:

Permission check
Business logic
Log records

Summarize:

The whole implementation of the 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 permission processing, logging and other public operations. This is both a clever place and the most likely problem, because the client uses the object is not the object it imagined, 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 seems to be less likely to do similar operations.

PHP uses Magic method to realize quasi-AOP