Category: PHP

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
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 = Nbe_GirlVsZombie_Player_GirlWithDragonPunch;

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();
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 a big thanks,

See you next time
Nick Belhomme

Zend Framework 2.0 Cookbook

Hello my dearest reader,

You have probably heard about a PHP framework called Zend Framework. If you haven’t, you break my heart.
It is the coolest thing on the block. Already it has been around for a couple of years and has proven its value in almost all enterprise applications World Wide. Some use it as a component library, others use the full stack MVC implementation. If you still not know what I am talking about you have probably booked a one way ticket to the moon and lost all connectivity (despite your smartphone).

What is more is that Zend Framework will be releasing a 2.0 version in the first half of next year (2011). That means within a few months. You will need some guidance because the changes are huge! A complete new MVC implementation, autoloading and plugin broker system, namespaces, Exception handling, backward compatibility breaks and so on. Well, that guidance will be available with a book that will be published shortly after the version 2.0 release.

I proudly present to you the “Zend Framework 2.0 Cookbook”

You will be able to pick it up at all major bookstores near you and of course on Amazon.

The book is being written by me in close relationship with some high key Zend Framework profiles. Every one of us contributes and takes a very close look at the 2.0 framework which should make it THE reference for the 2.0 branch.

Because it is a cookbook it is more targeted to the developer who wants to know how to get something done quickly instead of building an entire application before actually understanding it. You can use it to start
building a ZF application but the target is the developer who already has some knowledge with version 1 and wants to know how to do it in zf2. It tries to fill the gaps in the official documentation and thus works closely
together with that resource. Providing a quick reference and plenty of example codes should help the beginning zf developer as well as the more advanced.

If you want to keep updated on the release of this book, follow me on Twitter, Facebook or this blog.
Soon I will start to publish short tips from the book, already helping you to better understand Zend Framework 2.0

Have fun with Zend Framework 2.0, its release is closer than you think,
Nick Belhomme

Attend my presentation at the PHPBenelux 2011 conference

Hi ladies and gents,
I am happy to announce I will be speaking at PHPBenelux Conference 2011.
That means you will learn something about namespaces in PHP. If you never worked with them before or aren’t feeling very confident using them, attend this presentation. Namespaces are a crucial tool that should be found in every PHP developers toolkit (don’t be a dinosaur and in a couple of years a fossil).

If namespaces is not enough for you to attend this awesome conference, maybe the other speakers do the trick. Amongst several others are Rob Allen the main author of Zend Framework in Action and a contributor to the Zend Framework. He is also a member of the Zend Framework Education Advisory Board and will be giving a talk that will introduce Zend Framework 2 and look why it has been created and what’s different compared to ZF1.
Derick Rethans most famous for creating Xdebug, a tool every PHP developer uses on a daily basis (you practice Stepping and do unit tests right?). He is also the author of several books and will bring his geolocation know-how to the scene.
Elizabeth Naramore co-author of several PHP books and community development manager at Geeknet which includes sites such as SourceForge, Slashdot,, ThinkGeek. She will jump start the conference as a keynote speaker.

Still not convinced? Check the many high profile speakers who will be attending.

You should register your seat now, and look forward to ride a highway of information, plunge into networking (the social bowling event will help with that!! Whaaat there is a bowling alley? Yes there is!) and generally have a blast of fun!


See you at the PHPBenelux conference – January 28 & 29, 2011, Antwerp, Belgium

yours truly,
Nick Belhomme

update 2010-11-22: The Schedule is available