Author: Nick Belhomme

Zend Framework 2.0 Dependency Injection

Dearest Zend Framework and PHP Addict,

You know I always try to keep a close watch on the developments of Zend Framework 1.* and Zend Framework 2.0. Today I will blog about the Dependency Injection Component that is going to ship with ZF2.0.

What is dependency Injection?

You have been using dependency injection from the first time you started using classes. After this article you will have an ah-aaaah moment and you will finally be able to name the practice you have been doing all along. Almost each class has dependencies to other classes. You could instantiate these dependencies inside the class itself, making sure the dependency is always met, also avoiding the overhead of injecting it each time. While this seems a good idea in the beginning, it also tightly couples your application units. Also the quality is harder to guarantee because during unit testing your code has dependencies which are instantiated from inside the class to be tested. This makes it very hard to manipulate the state the dependency might have. The solution is to never instantiate the class from inside the class itself but from outside and let it be set as a parameter.
A good PHP resource on why you need dependency injection in PHP can be found at Ralph Schindlers blog article: Learning about Dependency Injection and PHP

What is a dependency Container?

Having to instantiate and pass the dependency all the time can be troublesome to say the least.
The first PHP solutions were to have a registry which would hold all the instantiated objects and only this registry would be tightly coupled in your architecture. This went a long way but still tightly coupled your architecture.
To remedy this people started looking into a good component which could really hold dependency definitions – a configuration which holds all classes / methods and their dependencies. And would also hold an instantiator, and container. The Instantiator would instantiate the objects for you according to the definition and a container would hold previous instantiated objects.
A good article written by Padraic Brady and published in 2008 pens down this idea and proposes a Zend Framework Dependency Injection Component, or simply Zend_Di: The Zend Framework Dependency Injection And Zend_Di

The Current Day: Zend\Di

Zend Framework 2.0 is currently under full development, several milestones have been completed. Probably the most important milestone of ZF2.0 is the MVC. To be fully compliant to current standards a good Dependency Injection (DI) component had to be developed.

_Why_ does ZF2 need DI for the MVC?
The reason is that it’s a good potential answer to the question of “how do controllers gain access to their dependencies?” In ZF1, the answer was either indirectly via Zend_Registry or the Bootstrap together with getInvokeArg()), or via direct instantiation within the controller. The latter is problematic as you can’t easily provide substitutions, and if the class instantiated needs to interact with resources — say, a web API, the database, etc. — this becomes difficult to mock when testing. In the former cases, you’re introducing undocumented dependencies in the object — looking simply at the controller’s API, you cannot easily guess what other objects it uses.

DI helps answer this. The prototype Zend Framework Core Team started building assumes that a DI container is composed into the front controller, and controllers are themselves defined in the DI container. When a controller is matched by the router, the front controller then pulls the matched controller from the DI container — along with all of its dependencies. This helps solve the initial question, but also answers another one: how to reduce the number of objects necessary for each given request. In ZF1, every single application resource is instantiated on every request, regardless of whether or not a controller uses it; the DI approach largely removes this, though at the expense of an in-memory graph of object definitions. However, the latter is usually smaller over-all, and easily cached in memory.

Ralph Schindler (Part of the Zend Framework Core Team) takes the lead on this component and listened to the community. He poured all those ideas in a component that can take prior configured definitions, detect dependencies at runtime and a tool for static dependencies analysis.
The approach that has been taken is that different environments will behave differently from a DI perspective. The solution is to consider anything but your local development machine production. Application in production should be stable from a code perspective and unchanging code means the deploy tool should be able to statically parse your code and create a definition file from it. This can be done automatically on each deploy. Once a definition file is ready – this will be in PHP format for maximum efficiency – your application doesn’t need to analyze your code on every request, thus gaining in huge performance benefits and without the hassle of always manually configuring all dependencies. Of course some dependencies will have to be manually configured, but Zend\Di offers tools for that.

Let’s take a closer look at the tools Zend\Di offers.

Zend\Di\DependencyInjector

This class will be instantiated most of the time. It will be used to retrieve instances configured by a definition.
For this you will need to set the definition object or manually configure everything piece per piece.

$di = new Zend\Di\DependencyInjector();
$di->getInstanceManager()->setParameters(
    'My\A',
    array(
        'password' =>'bar',
        'username' =>'foo',
    )
);
$c = $di->get('My\C');

In this example class C is instantiated. Class C has a dependency on class A, This is automatically behind the scenes detected by Zend\Di\Definition\RuntimeDefinition. Yet class A has constructor dependencies also, which can never be automatically injected so for this we need to set these parameters. This means that we need to aggregate all dependencies which cannot be automatically instantiated into a definition file. Even automatically detectable dependencies at runtime would benefit from a definition because compiling shouldn’t be done at runtime — it’s expensive. You will typically compile once, and then create a class extending ArrayDefinition that uses the results of compilation.

Zend\Di\Definition\Compiler

Creating a definition file asks a lot from a developer so it would be best that it could be automated as much as possible. For this a static compiler is implemented. Which has stated before should not be done at runtime during production.

$compiler = new Zend\Di\Definition\Compiler();
$compiler->addCodeScannerDirectory(new Zend\Code\Scanner\DirectoryScanner(__DIR__ . '/Game/'));
$definition = $compiler->compile();
$di->setDefinition($definition);
$commandParser = $di->get('Game\CommandParser');

$definition will be a complete Zend\Di\Definition\ArrayDefinition which accepts and outputs a PHP array based definition.
You can only have one definition at a time – hence the setDefinition and not an addDefinition api – so calling setDefinition() and passing an ArrayDefinition will result in no more Runtime lookups. If you want to combine the two strategies, you need to use an AggregateDefinition. An AggregateDefinition acts as a queue, querying each attached definition until it finds a match (or doesn’t!). As such, you would attach any compiled ArrayDefinition objects first, and a RuntimeDefinition object last.

Combinations of a definition and setParameters are also possible:

$di->setDefinition($definition);
$di->getInstanceManager()->setParameters(
    'Game\Grid',
    array(
        'gridSizeX' =>  2,
        'gridSizeY' => 5,
    )
);
$commandParser = $di->get('Game\CommandParser');

Parameters set through options or through the setParameters method are not only used for the __construct method but also for the available setters. This makes your code a bit hard to understand because you have no idea which parameter is used for what method. So parameters are nice, but the current incarnation also allows specifying per-method configuration for parameters that should be called at instantation (i.e. setter injection). In fact, it’s the preferred method for specifying configuration even for the constructor.

$di->getInstanceManager()->setMethods(
    'Game\Grid',
    array(
	'__construct' => array(
		'gridSizeX' =>  2,
		'gridSizeY' => 5,
	),
        'setPosition' => array(
		'x' => 1,
		'y' => 3,
	),
    )
);
$commandParser = $di->get('Game\CommandParser');

In the case where CommandParser needs to automatically accept a Grid object as a constructor parameter, you can even pass the constructor params for Grid directly to the get method of the main class:

$commandParser = $di->get(
    'Game\CommandParser',
    array(
        'grid' => array(
            'gridSizeX' =>  2,
            'gridSizeY' => 5,
        )
    )
);

The Injector will inspect the constructor params for CommandParser and if it doesn’t have a $grid param, than it will save the param for creating a params instance that might need it. In this case the Game\Grid $grid. This way you can pass params all the way down to the last dependency needed for instantiating the class you asked.

Or to make it even a bit more flexible you can even create aliasses and pass them as the second parameter.

$di->getInstanceManager()->addAlias(
    'my-Grid',
    'Game\Grid',
    array(
        'gridSizeX' =>  2,
        'gridSizeY' => 5,
    )
);
$commandParser = $di->get('Game\CommandParser', array('grid' => 'my-Grid'));

Aliases are intended to make it simpler to specify dependencies and/or substitutions. As an example, I might alias Game\Grid to “my-Grid“, allowing me to call $di->get(‘my-Grid’) and retrieve that class. This means that I could potentially configure the container differently, and get an object of a different class later — which is very useful for testing, or having different adapters for different environments.

So this is basically the standard usage of the Dependency Injector. Of course the DI is still BETA, and it shows.

Zend\Di leans heavily on Zend\Code\Scanner and here are still some caveats. At the time of writing the MethodScanner or ParameterScanner needs to be fixed to allow for the method signature:

public function __construct(Request $request, Response $response, Grid $grid, Inventory $personalInventory)

At the moment this signature breaks because of the start of the tokens for each Parameter.
It does however accept:

public function __construct(Request $request,Response $response,Grid $grid,Inventory $personalInventory)

As you can see the whitespaces between the parameters have been removed. Bottom line the Scanner should not be so error prone.

For my own testing I have forked ZF2 and fixed this issue in the branch https://github.com/NickBelhomme/zf2/tree/bugfix_tokentrim

As you can see all is still under major development, but that doesn’t mean you cannot play with it. So if you are interested in learning something about Dependency Injection and maybe even ZF2 in general I suggest you take a look at it.

I had a lot of fun inspecting the component and a lot of banging my head into the walls for comprehending the stuff described above. And honestly I couldn’t have completely grasped it without the excellent help and feedback of two special people deeply involved in this project: Matthew Weier O’Phinney and Ralph Schindler. Thank you both for the feedback which helped me in writing this blog post and spreading the knowledge.

A good code resource to mention is a forked and brought up to date repo with the current ZF state: https://github.com/NickBelhomme/ZF2ByExample

Sunny Greetings From Belgium and happy Zend Frameworking!

Nick Belhomme

Quality Assurance in PHP projects

Hello my dearest Unit tester,

My profession is assuring quality in IT projects. For this I implement systems at my client their work environments so that development teams can deliver the best code possible. I also give workshops and recently I gave one at PHPBenelux on Quality Assurance in PHP Projects. It was a 4 hour workshop and got very good feedback.
The slides are here: http://www.slideshare.net/NickBelhomme/php-quality-assurance-workshop-phpbenelux

One of the feedback I got was also related to the PHPUnit training course excerpt I released some time ago to the community.
The reason why I did this is because I felt Quality in software projects can and should be assured. Quality assurance (QA) is not only lacking in most PHP projects but often – most of the time – projects in other languages such as Java or .Net also lack them. Operating systems, application, games and sites are often released followed immediately with a continuous stream of bug fix patches. This means quality assurance is not a language specific problem, but a project problem. Because independent from the language you are using , as soon as you do not have a quality assurance system in place you will sooner or later face a problem. After receiving a lot of requests asking for the demo project from the excerpt I have decided to put it on-line on Github.

It is on-line under a creative common license, meaning you can contribute freely to the project.
The only thing you need to do is create a Github account, fork the project, implement your improvements and or feature requests and then do a pull request.

The project is dependent on PHP 5.3 or higher and uses namespaces, SPL Exceptions, Closures. In short the works for you to play with all these latest programming technique introduced to the PHP community 2 years ago with the launch of PHP 5.3

A big thanks to Zend for hosting the project at http://nickbelhomme.projectx.zend.com.
They make certain all the necessary tools are available and updated to the latest versions.
This way you can see the project in action. It is a text-adventure game which accepts only text input.
Generally you will need to use commands such as “look”, “take”, “open”, “go to”, “use” and many others to advance in the game.

Have fun,
Nick Belhomme

How I explained Object Oriented Programming to my wife.

The other day I had to interview a lot of PHP developers for my role as team lead in this ultra cool Belgacom Project. I interviewed many and on their resumes they all looked to be very proficient and have a lot of years of experience. One of the things I was looking for were good PHP developers with an excellent grasp of Object Oriented Programming. All of the developers claimed to be proficient in PHP5 and some even put an OOP expert status. Yet during the interview they failed miserably. Linking my questions about Interfaces and Abstract classes to a Java interview…

When I told my wife about the candidates I send home she asked me why. Here is the excerpt of that conversation.

Chanie: You keep interviewing all those PHP programmers? Aren’t they any
good?
Nick: The problem is a lot of them didn’t evolve with the programming language.
Chanie: What do you mean?
Nick: Well PHP5 is released July 2004. That is almost 7 years ago. If you take a look at the average life cycle of an application that means a looooong time ago. Applications that still run on PHP4 are considered fossils. So how can a developer justify not to learn PHP5 and all it potential and still dare
to say I am proficient in PHP5?

Because upgrading your server to PHP5.* is not the same as using PHP5.

Chanie: If upgrading your server and thus running your software on the latest build isn’t PHP5 programming, then what is?
Nick: In PHP4 it was possible to perform object oriented programming but very limited and certain workarounds needed to be taken. That meant almost nobody used classes, and those that did, most likely did it wrong.
Chanie: what do you mean did it wrong? A class is a class, what is more to it?
Nick: Well you have to know what kind of logic you have to put in a class and how to implement it nicely so you do not simply wrap procedural code within a class statement. That means keeping
classes lean and small, only doing things for what they were designed.
Chanie: What do you mean doing things for what they were designed? You decide what their design is!
Nick: Indeed it is the developers responsibility to think about the class its design before implementing it. This means splitting your logic in several classes which are loosely coupled.
Chanie: What do you mean loosely coupled? I have been writing classes a long time but this is the first time I hear about that.
Nick: Well that is because you aren’t really doing oop.
Where is the reusability and flexibility if everything is strongly coupled? When you try to make classes loosely coupled you try to make the dependency between two classes to a minimum. If class A must be coupled with class B it
would be much nicer if you indicate the dependency using an interface and not an actual implementation.
Chanie: What has an interface got to do with coupling?
Nick: An interface defines a contract listing all the public methods a class must implement so that the Client knows which methods will be available when he uses a class that implements the interface. There is a huge difference between giving a class direct knowledge of one class to another, which is based on implementation, rather than based on a contract. When a system is dependent on an actual implementation it is considered strongly coupled. In loosely coupled the client doesn’t need to know which class is used as long as it implements the interface which means a new class implementing the interface can be written to replace the current dependency, without the need to change the dependent class. New and old classes can be changed interchanged freely. Strong coupling doesn’t allow this.
Chanie: aaah that makes a lot of sense. I heard about interfaces but I thought it was to let the client know which methods were available, and I never thought about the consequences or why it should be used in real life scenarios.
Nick: Well now you know.
Chanie: But this raises the question about Abstract classes, they are also a kind of interface. Because you have to extend them before you can use it. And if you would use the abstract as the
contract it would provide the same purpose.
Nick: Indeed it would, but an abstract class has implementation details which are common between all extending classes.
Chanie: Indeed that way you are also strongly coupling the client to a definite implementation and thus when a certain common method implementation needs to change, you also need to change the client. Now that I Think about it, it would be better to let the abstract class implement the interface and make the dependency towards that.
Nick: Right, also besides implementing common logic in an abstract, it can also be used to enforce a kind of algorithm, without knowing all the details of the algorithm required.
Chanie: Huh, you lost me?
Nick: Imagine you want to implement a web service client.
You could implement everything with the Soapclient class but you could also abstract it. Creating a common interface for all your clients, SOAP, XML-RPC, etc. Then in your abstract web service class you implement
all the common logic in the abstracted methods. Keep all naming abstract, the interface should be abstract such as doRequest() and not something like doSoapRequest().
Chanie: ok but what about that algorithm?
Nick: I’m getting there. So now that you have defined the requirements you know all the potential service clients will have a specific implementation for the doRequest(). So you make that method abstract enforcing the extending classes to implement it accordingly. Now from a client perspective you instantiate the kind of service client you need:
SoapClient or Xml-Rpc and when you make the getLatestNews() method, internally the doRequest() method is called. So both classes share the same algorithm in getLatestNews and the only thing that differs is
the actual implementation doRequest, but this is of no matter because the algorithm doesn’t need to know that exact implementation. It only needs to know it has to call it on that exact moment in time.
Chanie: aaaah now it becomes clear. I only knew about the shared use case for abstract classes. But I didn’t know about hiding the exact algorithm details use case.
Nick: That is because people often do not use it correctly. Most people I know use an abstract class to create a collection of static utility functions into a class and then declare it abstract so nobody can instantiate the abstract class directly.
Chanie: Aaaah yes static functions and properties. I like those, it gives me back the power of scripting. I have a bunch of functions I declare static and put them in a class and voila, everything is nicely packaged.
Nick: Wrong my young padewan. You are going to the dark force. It is a dark but powerful path you follow. But in the end it will lead to your own destruction.
Chanie: explain!
Nick: Static methods are not created to facilitate your packaging needs. If you want to do packaging try namespaces using the conventional PEAR naming convention, Vendor_Package_Date_* or the real namespace deal introduced in PHP5.3, which is already almost 2 years old… Static
methods are created to assist in creating instances of a specific class. A class with a private constructor can never be instantiated and is thus useless, unless it can be instantiated using a public static method. The
only purpose of this method is to check whether an instance already exist and if not create it and store it in a static property, otherwise return it immediately. This is called a singleton and will make certain
only 1 occurrence or instance can exist from a certain class. Static methods are also used to create and configure instances from classes which use a common interface. Thus you do not instantiate a concrete
class yourself but let a factory do this for you. So your client never knows which class is actually instantiated but it is decided through the means of a configuration detail from inside or outside the factory
itself. You now see the power of interfaces? It promotes polymorphism.
Chanie: Polymorphism isn’t that some kind of alien probing creature??
Nick: lol, no it isn’t. It is the ability to let the client work with various types. An interface can be implemented in several ways but those implementations can be interchanged freely. Even dynamically if you want.
Chanie: Dynamically, but isn’t it only possible during instantiation?
I have created a small powerful game… And demonstrates what you call polymorphism. In this game I am girl who can attack zombies. I have 2 public methods: look and attack. In the beginning when I attack I use my fists. But after taking a powerup I will be able to shoot fireballs.

$player = Nbe_GirlVsZombie_Player_Girl;
$player->attack();
$player = Nbe_GirlVsZombie_Player_GirlWithDragonPunch;
$player->attack();

Nick: Yes it demonstrates what I call polymorphism. Both Players have a different implementation and yet can be freely swapped because the interface is your contract. But it is not really dynamic, you still have to really instantiate different types and what if you want your player
to all of the sudden have night vision? You would have to create another player type. It would grow exponentially and become a nightmare to handle… Better to do that dynamically using a strategy, injecting the behavior you need at the fly.
Chanie: oooh that is sooo cool.
Nick: isn’t it? Well I would get me a girl instance using a factory:
$player = Nbe_GirlVsZombie_Player::factory();
$player->setAttack(Nbe_GirlVsZombie_Player::factory(‘fist’));
$player->attack();
$player->setAttack(Nbe_GirlVsZombie_Attack::factory(‘dragonPunch’));
$player->attack();
$player->attack();
$player->setVision(Nbe_GirlVsZombie_Vision::factory(‘night’));
$player->look();
Nick: In this example you see polymorphism, static methods and interfaces being used. You see how Object oriented programming is so much more than just a class and some code in it. You need to really think and put logic where it is needs to be put. You do not want to put the code of an attack in the player its class because that would be putting the logic in the wrong place. The attack function should
delegate the attack to attack instance but not through a strongly coupled design decision but through a loosely coupled design by using an Nbe_GirlVsZombie_Attack_Interface which every attack must implement.
Nick: I hope this is all become a little bit clear.
Chanie: ooh yes it has become clear I still have a lot to learn, but thanks to this conversation I have a better understanding and I am eager to put it in practice.
Nick: glad to hear that! Have fun with OOP!

Well that was my complete conversation. Of course a potential team member has to have a lot more than good OOP skills, he or she will have to have the right social skills and mentality. OOP you can learn, but
behavior skills are a little harder to tackle…

Sunny Greetings,
Nick Belhomme

Mastering Namespaces in PHP at PHPBenelux Conference

On Saturday 29th January I held my Mastering Namespaces in PHP presentation at the PHPBenelux Conference. The second edition of this awesome conference has put the conference on the European map as a classic must-go-to. The ratings are through the roof!

See what attendees are saying:

  • “already the best conference of the year”
  • “Great conference! The best i had in years.”
  • “5 THUMBS UP!!”
  • “Top class speakers, which make a good schedule”

I must say I am really happy I was part of making all those people have a wonderful day by giving the Mastering Namespaces in PHP Presentation which was – although for some people lacking some colour in the black and white slides – regarded very good:

  • “Spot on. All aspects of namespaces were covered, and explained well. Included with examples & references”
  • “The subject was well covered, and Nick clearly knew what he was talking about.”
  • “Good presentation about namespaces! Good explanation about how it works, some pitfalls and best practices. I liked it a lot!”
  • “Clear introduction into Namespacing in PHP with the good and bad clearly outlined. Very informative and thorough.”

To all the people who attended and took the time to rate my presentation at joind.in a big thanks,

See you next time
Nick Belhomme