When you work with the ZF2 Dependency Injection Container (DiC) when you make multiple requests for an instance of an object you will get the same object back each time. [...] But what if you want the injection benefits of the DiC but don't want to share the object? Use the DiC's newInstance method instead with the third parameter being false.

He includes code examples of requesting the object both ways - the usual way that returns the same object and the alternative that passes in a "false" value, complete with a debug output of each object proving they're different.

Resting on the foundation of Polymorphism (dynamic Polymorphism, not the ad-hoc one often achieved through plain method overriding), Virtual Proxies are a simple yet solid concept which allows you to defer the construction/loading of expensive object graphs without having to modify client code.

He shows how to create a collection of domain objects that use proxies to populate their data. He includes the code for creating a "Post" interface/object as well as a Comment interface/object. These are put into a "CommentCollection" and, when it's accessed, pull the item in the collection out, only populating the data on demand.

If you have a PHP application that makes heavy use of objects (which is probably 95% of you reading this) then you will have objects with constructor methods in them. It is also very likely that there is some stuff going on in those constructors. So how do you test things like this?

He includes a sample constructor that creates a container, pulls out some configuration values and reassigns them to class properties. He first tests that these properties have been set correctly by mocking out the object and overriding the configuration settings in the (dependency injection) container.

With such an extensive array of tests [at work], I have received an education in what it really means to write unit tests for live, production-ready code that really takes unit testing seriously. [...] If you are really writing your unit tests the way you should, each test is focusing on testing one bit of functionality in isolation, which means that you will be heavily relying on mock objects to make things work. I've come up with an example scenario that I hope goes a long way to explaining how to effectively use mock objects.

In his example, he shows how to mock out two objects, "Foo" and "Bar" that are passed into a method in his "Alpha" class. He looks at the code for the "Foo" class and creates a mock object based on its contents - two methods: "getId" and "getDetails". He does the same with the "Bar" class, mocking the "getStartDate" and "getEndDate" methods and showing how to pass those into the "munge" method on the "Alpha" class, complete with return values to match the tests.

For more information on PHPUnit's mock object support, see this page in its manual. You might also explore another popular option, Mockery.

A few days ago I was explaining mocking to a few colleagues. I came up with the following quick n dirty code to show them the elegance of Mockery as a mocking framework. The code is straight-forward: it checks the health of a server using a tiny heart beat script.

He provides both sides of the code - a simple "heartbeat" script that just responds with a JSON result, the class to consume it, a HTTP wrapper class that will be the target of the mock and his PHPUnit tests (testSystemIsOnlineWhenServiceRuns). You can see the use of the Mockery tool in this test.

In the PHP world, probably the Doctrine ODM for MongoDB is the most successful. This followes to the opularity of Mongo, which is a transitional product between SQL and NoSQL, still based on some relational concepts like queries. [...] The case for an ODM over a plain Mongo connection object is easy to make: you will still be able to use objects with proper encapsulation (like private fields and associations) and behavior (many methods) instead of extracting just a JSON package from your database.

He briefly mentions that the PECL extension for Mongo needs to be installed prior to trying out any of the examples. His first example shows how to create a DocumentManager (similar to the normal EntityManager for those familiar with Doctrine). He also shows an integration with the ORM and shares some of the findings he's made when it comes to versioning the resources (hint: annotations are your friend).

We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.

In our last PHP Ad Tracker lesson, we constructed the database tables for our ad banner application. Now we are ready to construct the data object that will hold the variables and functions that will display, add, edit and delete the data in those tables.

They cover each of the variables they'll be using with a summary of what they're used for as well as the various functions to be defined and what they'll return. Following this, they get into the actual development - creating an "ads" class and defining the methods to get the current ad count, get the number of clients and pull the actual client/ad data.

Mocking objects in unit tests is pretty straightforward as every object used in a test case is usually created in a scope of one test class. In functional tests it's a bit harder since we either don't have full control over objects being created or it's simply too laborious to mock half the framework. [...] We're getting the service from a container [in the example] and calling a method which should send a lead. The problem is we don't want to actually call an API while executing Behat scenarios.

Rather than hitting up the API for each test, he opts to create mock objects and results with the tools Mockery has to offer. He gives code for a "is API available" method that either returns a valid container or a mocked object, depending on how it was called.

However, it didn't stop there; there was also the addition of Closure::bind() and Closure->bindTo(). These methods are identical except one is a static method into which the closure is passed, the second an instance method on the closure itself. These methods both take two arguments (on top of the closure for the static version): $newthis and $newscope. What this means is that unlike the regular object model the concept of $this and lexical scope (what is in scope for the function with regards to private/protected methods inside objects) are completely separated.

He also mentions that you can change the "$this" to a different object (complex) or swapping out the object the closure is bound to while keeping "$this" the same (simpler). He mentions that it could be useful for unit testing but can have its drawbacks. He's included code to illustrate the breakage it can cause in the PHP OOP model (with an explanation).