In an interesting post to his blog Ahmad Hajjar shows you how to use to Go! PHP AOP framework to help mock objects in your unit tests. The Go! AOP framework provides some of the base functionality for using aspect-oriented programming techniques in your code.

These have been always very important questions in software development industry; what should I test in unit testing? And how can I make tests as small as possible, and how to avoid testing already tested code? or 3rd party libraries? [...] In principle, unit test must fail for one and ONLY ONE reason, this makes sense actually, as it complies with the S in the SOLID object-oriented design principles. [...] We can use mocks in the problem listed above, to make the unit test, real unit test, that is testing only the things that needs to be tested. [...] However, what we are going to do today is something different. OK! Why should we re-invent the wheel? the answer is : because it is simpler wheel ! also it is a wheel that uses different technology which is AOP.

He uses a simple Laravel application and the Go! framework for his testing examples. He uses the AOP functionality from Go! as the mock handling instead of something like PHPUnit's own mocking or Mockery. He shows how to configure the AOP functionality first, then creates a basic aspect class with a few interceptors for method calls. He creates an AopMocker class that adds the class requested to the mock configuration. Finally he improves the initial unit test example using these tools, building mocks for User and Post classes and making the same assertion.

Ed Zynda has a recent post to his site looking at the use of the Interceptor design pattern with the aspect oriented methodology in PHP. He doesn't get into the basic concepts of AOP, so you might want to find out a bit more in other places. It's not a necessity, though, as his code examples are easy enough to follow along.

There are many ways to modify the behavior of existing code with actually changing the core logic. Some patterns you might be familiar with are the decorator pattern or the observer pattern. Both allow you to take another object and modify the behavior by wrapping your modifications around the original code. One pattern you might not be familiar with though, is the interceptor pattern.

He first helps you install the AOP-PHP extension to provide some of the necessary PHP functions. From there he talks about using some of the functions that intercept function calls and perform an action. He shows examples of it using:

• aop_add_before
• aop_add_after
• aop_add_around

He also shows how to modify arguments during execution and changing return variables when the execution of the function is completed.

On the /r/php subreddit on Reddit.com JustSteveKing asks the community about Aspect Oriented Programming. Aspect Oriented Programming makes use of cross-cutting concerns (modular functionality) along with encapsulation to make for more modular code.

What are the general thoughts on AOP? Anybody using it? After reading several articles and tutorials on the matter I have to admit it seems to have its plus points. The only thing I am wondering at this point is why is it not a widely adopted as MVC, I mean there must be a reason?

Most of the comments either fall into two categories. Either the commenter has made use of it in a limited fashion (like logging) or doesn't use it at all. There's also a good comment about some of the risks involved in its use and the "magic" that can come with it. Additionally, there are links to other articles for those wanting a good introduction to AOP and what it can do.

Ramon Kleiss has posted a tutorial to his site recently introducing you to the concept of AOP in PHP (Aspect Oriented Programming). In it he provides an overview of some of be basic AOP concepts and code examples showing them in action.

For my first blog post, I'm going to take you on a little trip into a really cool programming paradigm: aspect-oriented programming, which is a little known style of programming while it can come in really useful. It is common knowledge that in software development you should have a Separation of Concerns (the first letter in SOLID). Although it is accepted that the Single Responsibility Principle is hard to design, it is still valued as one of the top best practices one can use.

He starts with a base class (ArticleManager) and how it's easy for it to grow when more dependencies are needed. He then evolves this example to use a more AOP approach, resolving the scope creep in the main class using cross-cutting concerns, advice, pointcut and aspects. He moves away from his basic example and uses a Symfony-based example to show how to implement a LoggingPointcut, inject it into the class and set up an "intercept" method to handle the notification of which method was called.

You will have to be careful to remember that you are using AOP as the application development continues, since it is very easy to forget about if you're happily developing away. Just take this rule of thumb: does the class I'm modifying care about the extra functionality? If it doesn't see if you can use inheritance or see if you can use AOP.

In a new post to the "imagine easy" blog Yitzchak Schaffer looks at Aspect Oriented Programming in PHP and pushing the limits of some of the work already done in the area.

Here’s the premise [of Aspect Oriented Programming]. A given piece of code exists for a certain purpose - let’s say, to retrieve a record from a database. But there may be any number of other things that need to happen in addition to the actual retrieval: logging, access control, caching… those are known as cross-cutting concerns - issues that are relevant across the codebase, but are not specifically relevant to any one piece of code where they might be needed. And being that these bits of functionality are not intrinsically connected with data retrieval, in our example, it would make sense for them to be disconnected from the retrieval implementation.

He includes some example code showing the migration from a typical logging example, moving the logging code away from the other parts and into an "aspect". He briefly mentions some caching functionality and talks about how one PHP framework, Lithium, makes use of these kinds of AOP principles. He offers an alternative in the form of subtypes, and example of which he's implemented in a tool of his own, Camphor.

PHPMaster.com is back with the third part of their series looking at Aspect Oriented Programming with the CodeIgniter framework. (Part 1, Part 2)

In the previous parts of the series we learned about AOP concepts and the need for using AOP in large scale projects and I introduced CodeIgniter’s hooks as a convenient mechanism for creating AOP functionality from scratch. In this part I’ll show you how to use both XML and comment-based techniques to create custom AOP functionality when a dedicated AOP framework is not available.

They start with the XML configuration that defines a few aspects and pointcuts for the application. This is then read in via the "applyBeforeAspects" and the aspects that should be executed first are extracted, loaded and run. Following this, they take the other approach - based on docblock comments - and pull in the comments (the @before and @after tags) and load/execute the aspects that way instead.

Matthew Weier O'Phinney has a new in-depth post to his blog that looks at a few features of Aspect Oriented Programming and what technologies are out there that help support it right now. He mainly focuses on the features of the Lithium framework because of its filtering techniques.

Last month, during PHP Advent, gwoo wrote an interesting post on Aspect-Oriented Design, or Aspect Oriented Programming (AOP) as it is more commonly known. The article got me to thinking, and revisiting what I know about AOP, Intercepting Filters, and Signal Slots -- in particular, what use cases I see for them, what the state of current PHP offerings are, and where the future may lie.

He gives a base class to help make things a bit clearer for the rest of the post - a simple Foo instance that uses a Listener interface to "doSomething". Matthew also talks about intercepting filters (extracting things like logging/debugging out of the code and put on its own) and signal slots. For both, he gives examples of how Lithium handles them and some of his opinions on the methods. He points out a few concerns that he has for the current state of AOP in PHP (frameworks) and suggests that, if you haven't looked at these ideas, you do so sooner rather than later.