$Monitoring = new Aspect(); $pc3 = $Monitoring->pointcut("call *::*");
Как показано в примере, мы можем воспользоваться маской *::*. Далее в Advice мы можем воспользоваться традиционной функцией вычисления точного времени в миллисекундах
function getMicrotime() { list($usec, $sec) = explode(" ",microtime()); return ((float)$usec + (float)$sec); }
С помощью этой функции мы можем замерять время на входе в каждую функцию проекта и сверять его с показаниями на выходе из этой функции, а время выполнения операций бизнес-логики в теле функции помещать в глобальную переменную отчета. Осталось лишь вывести на экран отчет в конце программы. Пример использования аспекта мониторинга производительности представлен в скрипте sample_trace.php в архиве дистрибутивного пакета.
Чтобы у вас не сложилось мнение, что АОП помогает решать лишь какие-то частные задачи, давайте рассмотрим еще пример.
Как известно, PHP лояльно относится к типам переменных. С одной стороны, это не может не радовать нас, так нет необходимости постоянно заботиться о соответствие заданным типам и тратить время на их декларацию. С другой стороны - это причина множества возможных ошибок. При большом количестве функций в проекте едва ли возможно удержать в памяти заведенный нами же синтаксис для них. Но достаточно лишь поменять местами аргументы функции, и ее поведение может стать непредсказуемым. Может ли здесь нам помочь АОП? А почему бы и нет?! Давайте вспомним диаграмму, приведенную на . Как мы видим, классы Document и Record содержат однотипные методы add, update, delete, copy, get. Хорошо организованная программная архитектура подразумевает однотипный синтаксис для этих методов: add($id, $data), update($id, $data), delete($id), copy($id1,$id2), get($id). АОП нам может помочь организовать как программную архитектуру, так и самих себя. Мы можем завести аспект валидации входных параметров и определить диапазон Pointcut для методов классов Document и Record. Функция события входа для методов add, update, delete, copy, get может проверять тип первого аргумента. Если он не является целочисленным (integer), то можно смело сообщать об ошибке. Можно также завести второй Pointcut для методов add и update. В данном случае будет проверяться тип второго аргумента. Он, очевидно, должен соответствовать типу массив (array).
Таким же образом мы можем выносить за пределы бизнес-логики проекта протоколирование транзакций, мы можем в любой момент определить диапазон функций, требующих дополнительных проверок на предмет безопасности, и т.д.