Analysis of PHP’s AOP thinking

This article mainly introduces the analysis of PHP's AOP thinking, which has certain reference value. Now I share it with everyone. Friends in need can refer to it

Story background:

Question:

In traditional OOP (Object-Oriented Programming) thinking, applications are generally decomposed into several objects, emphasizing high cohesion and weak coupling, thereby improving the application modules However, when dealing with certain problems, OOP will not be flexible enough.

For example, many business logics in the application must perform "permission check" at the beginning of the operation and "permission check" after the operation. Logging", if the code that handles these operations is directly added to each module, it will undoubtedly destroy the "single responsibility" principle of OOP, and the reusability of the module will be greatly reduced.

At this time, the traditional The strategy often adopted in OOP design is to add the corresponding proxy layer to complete the functional requirements of the system. However, such processing obviously adds a layer of division to the overall system, and the complexity also increases accordingly, giving people an overly heavy feeling. Feel.

Solution:

It is to deal with such problems that the idea of AOP (Aspect-Oriented Programming) came into being. Assume that the application is thought of as a three-dimensional structure. , the sharp edge of OOP is to cut into the system vertically, dividing the system into many modules (such as: user modules, article modules, etc.), while the sharp edge of AOP is to cut into the system horizontally, extracting parts that may require repeated operations in each module (such as: permission checking, logging, etc.). It can be seen that AOP is an effective supplement to OOP.

As far as current PHP is concerned, there is not yet a complete built-in implementation of AOP. Although RunKit has appeared, it has always stayed in the PECL project in a BETA state. It is estimated that it is unlikely to become PHP for a long time. default settings. Does that mean AOP is broken in PHP? Of course not, because we have __get(), __set(), __call() and other magic methods. Proper use of these methods can achieve a certain degree of "quasi-AOP" capabilities for us. The reason why it is said to be quasi-AOP is because simply From an implementation point of view, it is a bit far-fetched to call it AOP, but from an effect point of view, it partially realizes the role of AOP. Although its implementation is not perfect, it is sufficient for general use.

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(); }

/** * 总结： * 整个的实现思路其实很简单，关键就是客户端请求的对象不能直接实例化出来， * 而是利用工厂方法返回一个请求对象的包装对象，在包装对象内利用魔术方法来处理权限处理，日志记录等公共操作。 * 这既是巧妙的地方，也是最有可能出问题的地方，因为客户端使用对象并不是它想象中的对象， * 而是一个包装后的对象，比如说，客户端通过getBizInstance()方法以为得到的对象是BIZ， * 但实际上它得到的是一个BIZ的包装对象AOP，这样的话，如果客户端进行一些诸如get_class()之类 * 和对象类型相关的操作就会出错，当然，大多数情况下，客户端似乎不太会做类似的操作 */

The above is the entire content of this article. I hope it will be helpful to everyone’s study. For more related content, please pay attention to the PHP Chinese website!

Related recommendations:

Basics of how PHP works

How to generate short links in PHP

The above is the detailed content of Analysis of PHP’s AOP thinking. For more information, please follow other related articles on the PHP Chinese website!