Time is passing and the requirements for the developed systems and projects become much more large-scale and complicated. The clear structure and “readability” of a program components code are very critical and important today as they influence directly the ROI increasing. Object-Oriented Programming allows us to organize the program code so that we can trace a business-logic of program components and taxonomy (hierarchical relationship) of the business-processes and entries. However we are discovering some other troubles during a new system development. We can twist in the hands a quite successful class diagram for a long time in order to choose a way of implementing a DB connector object or some parts of the environment into a certain classes. The point is that the objects should be isolated. If we had declared the permanent objects in the global variables, we would not be able to use a testing module (Unit Tests, http://www.testdriven.com). Moreover, we can see that a business-logic of some methods is being lost behind the system code insertions such as logging, caching, synchronization, and code tracing. It goes without saying we have to separate a business-logic and a through functionality (cross-cutting concerns). These tasks can be solved by means of Aspect-Oriented Programming (http://en.wikipedia.org/wiki/Aspect-oriented_programming).

The corner stone of this approach is Aspect. Any notion, process or perspective can be viewed through it. Aspect-Oriented Programming allows to present the through functionality as the independent declarations – the aspects. We can define the functionality for the precisely specified points (JoinPoint) such as method call, class initialization, access to the class properties, and etc. Set of those points (Pointcut) is used in AOP-based languages more frequently. The program code which is called an “Advice” specifies the JoinPoint points’ functionality. Thus, the through functionality of system components set is described in the aspect space. The components itself contain only a business logic that they are meant to execute. Components and aspects are connecting within the compiling process.

As you understand the mentioned circumstance complicates the realization of AOP in PHP. There are some projects that are aimed to overcome these obstacles in a different ways. Aspect-Oriented PHP (http://www.aophp.net) uses PHP preprocessor, which is written on Java 1.5. On the other hand PHPAspect (http://eee.easy-hebergement.net/~wcandillon/dokuwiki/doku.php) relies on the other way. It uses XML for aspect declaration. PHP executes compilation itself with the aid of eval() function. It is an interesting approach, but a PHP code in XML looks very poor.

In my turn I suggest less radical approach that is less universal at the same time. It is a class library of Aspect-Oriented Programming paradigm’s implementation into PHP. The library and the sample are available at http://www.phpclasses.org/browse/package/2633.html

Let us turn to the sample. We can specify an aspect of through functionality (for example, logging) with the help of Aspect class initialization. Then we create the pointcut and the point methods, which will be affected by the pointcut. Next we just specify input/output points’ program code for this pointcut. As you understand, we need to set the aspect pointer as a parameter to every component class and set up pointers of input/output points in every method ( advice::_before() and advice::_after() ).

This approach has a disadvantage though. We have to make the modifications to methods and classes. Besides, there is a limit in a class behavior control. On the other hand, the absence of PHP rebuilding necessity is the obvious benefit of this approach. Moreover, your component model may stay permanent.