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.

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.

On the Codeception site they've posted a guide to using the AspectMock feature of the testing tool to prove that "nothing is untestable."

We already announced AspectMock, the mocking framework that may dramatically change the way you do testing in PHP. In this video Jeffrey Way shows how AspectMock is different from others. In this post we will demonstrate its powers too, and we will try to break some stereotypes about PHP testing. To get the code tested, you should always keep in mind how you would write a test for it. We know unit testing requires some good practices to follow and bad practices to avoid.

Their first example involves testing singletons, notorious for being difficult to test because of their "global" state. He also gives a more practical example using a Yii2-based application and a login form. True to its name, the AspectMock uses Aspect Oriented Programming concepts to make the "magic" happen behind the scenes.

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.

In this new post to PHPMaster.com they continue their look at aspect-oriented programming with CodeIgniter. In part one they introduced some of the fundamentals of AOP and in this new article, they dig deeper with more practical examples.

In the previous part of this series we learned what Aspect Oriented Programming (AOP) is and the meaning of important AOP terminology. In this part I’ll explain why we need AOP using practical examples and how to add AOP behavior to your PHP application using the CodeIgniter framework.

They start with a look at a few pieces of functionality that could cut across multiple parts of the application like logging or authentication/authorization. They show how to use the "hooks" feature of CodeIgniter to implement the AOP proxy class generation, executing pre- and post-controller.

On PHPMaster.com today there's a new tutorial posted that wants to guide you through the world of aspect-oriented programming with a CodeIgniter application as a base.

Have you ever heard of Aspect Oriented Programming (AOP) before? It’s a widely used concept in developing enterprise level systems, although it hasn’t seen much use in PHP. I’m going to use this article as an opportunity to introduce PHP developers to AOP. This tutorial will be delivered to you as a 3-part series. In this part I’ll explain the concepts of AOP. In part 2 I’ll show you the practical uses of AOP and creating a AOP rules structure. Finally, I’ll show you how to integrate AOP functionality using CodeIgniter in part 3.

Since this is just part one, they mainly focus on some of the key points of AOP like aspects, advice, jointpoint and pointcuts. For each, there's brief descriptions for the types and, for some, code samples showing the idea in action.

In a recent post Marcelo Gornstein takes a look at using dependency injection with Doctrine2 using his Ding container.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

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.