Home

Welcome to the aopalliance/php wiki!

PHP AOP Alliance is the first step in integration of AOP across different PHP realizations. That repository will store whole the documentation about AOP, common interfaces, pointcuts syntax and much more. Like aopalliance.sourceforge.net for Java This will give developers more interoperability between libraries and frameworks.

List of AOP solutions available for PHP today:

• AOP-PHP PHP Extension
• Go! AOP PHP Library
• TYPO3 Flow framework
• JMSAopBundle
• Ray.Aop component
• Ding framework
• Seasar framework

AOP Overview

Aspect-oriented programming entails breaking down program logic into distinct parts (so-called concerns, cohesive areas of functionality). Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program.

Logging exemplifies a crosscutting concern because a logging strategy necessarily affects every logged part of the system. Logging thereby crosscuts all logged classes and methods.

All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to intercept express a limited form of crosscutting, without much support for type-safety or debugging. Each realization has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, like adding members or parents.

Terminology

Standard terminology used in Aspect-oriented programming may include:

• Cross-cutting concerns Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though each class has a very different primary functionality, the code needed to perform the secondary functionality is often identical.
• Advice This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method.
• Pointcut This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied. In our example, a pointcut is reached when the thread enters a method, and another pointcut is reached when the thread exits the method.
• Aspect The combination of the pointcut and the advice is termed an aspect. In the example above, we add a logging aspect to our application by defining a pointcut and giving the correct advice.

Type of advices

• Before advice A before advice is executed before the target method is being called, but cannot prevent the target method from being executed.
• After returning advice An after returning advice is executed after returning from the target method. The result of the target method invocation is available to the after returning advice, but it can’t change it. If the target method throws an exception, the after returning advice is not executed.
• After throwing advice An after throwing advice is only executed if the target method thrown an exception. The after throwing advice may fetch the exception type from the join point object.
• After advice An after advice is executed after the target method has been called, no matter if an exception was thrown or not.
• Around advice An around advice is wrapped around the execution of the target method. It may execute code before and after the invocation of the target method and may ultimately prevent the original method from being executed at all. An around advice is also responsible for calling other around advices at the same join point and returning either the original or a modified result for the target method.