PHP利用魔术方法实现准AOP

最新推荐文章于 2021-03-11 14:50:38 发布

Zach-vip

最新推荐文章于 2021-03-11 14:50:38 发布

阅读量1.6k

点赞数 1

分类专栏： php学习

php学习专栏收录该内容

26 篇文章 0 订阅

订阅专栏

在传统的OOP（面向对象编程：Object-Oriented Programming）思想里，一般把应用程序分解成若干个的对象，强调高内聚，弱耦合，从而提高应用程序的模块化程度，但是在处理某些问题的时候，OOP会显得不够灵活，比如说，应用程序里很多业务逻辑都要在操作之初进行“权限检查”，在操作之后进行“日志记录”，如果直接把处理这些操作的代码加入到每个模块中，那么无疑破坏了OOP的“单一职责”原则，模块的可重用性会大大降低，这时候传统的OOP设计往往采取的策略是加入相应的代理（Proxy）层来完成系统的功能要求，但这样的处理明显使系统整体增加了一个层次的划分，复杂性也随之增加，从而给人过于厚重的感觉。正是为了处理这样的问题，AOP（面向方面编程：Aspect-Oriented Programming）思想应运而生了，假设把应用程序想成一个立体结构的话，OOP的利刃是纵向切入系统，把系统划分为很多个模块（如：用户模块，文章模块等等），而AOP的利刃是横向切入系统，提取各个模块可能都要重复操作的部分（如：权限检查，日志记录等等）。由此可见，AOP是OOP的一个有效补充。

就目前的PHP来说，还没有一个完整的AOP内置实现，虽然出现了RunKit，但一直都以BETA的状态呆在PECL项目里，估计很长时间内不太可能成为PHP的缺省设置。那是不是AOP在PHP里就破灭了呢？当然不是，因为我们有__get()，__set()，__call()等魔术方法，合理使用这些方法可以为我们实现某种程度的“准AOP”能力，之所以说是准AOP，是因为单单从实现上来看，称其为AOP有些牵强，但是从效果上来看，又部分实现了AOP的作用，虽然其实现方式并不完美，但对于一般的使用已经足够了。特别是从PHP4.3.0开始，这些魔术方法已经成为了PHP的缺省内置实现，扫除了PHP4/5兼容的顾虑，那么就更加没

<?php

//应用程序中某个业务逻辑类

class BIZ

{

    public function foobar()

    {

        echo '业务逻辑<br />';

    }

}

//业务逻辑类的包装类

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 '权限检查<br />';

        $callBack = array($this->instance, $method);

        $return = call_user_func_array($callBack, $argument);

        echo '日志记录<br />';

        return $return;

    }

}

//工厂方法

class Factory

{

    public function getBizInstance()

    {

        return new AOP(new BIZ());

    }

}

//客户端调用演示

header("Content-Type: text/html; charset=gbk");

try

{

    $obj = Factory::getBizInstance();

    $obj->foobar();

}

catch(Exception $e)

{

    echo 'Caught exception: ',  $e->getMessage();

}

?>

有理由不使用它们。这里要说明的是PHP5对这些魔术方法的实现有些许的不同，下面偶们举例说明：

屏幕显示：

权限检查

业务逻辑

日志记录

总结：

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