When I first learned PHP 5’s object oriented syntax and rules, I didn’t see much of a point to the interface options. I felt that I could do more by defining abstract classes and at least filling in some of the methods with some details. Lots of people in the PHP world still aren’t 100% sure the reasons that interfaces exist, or the best way to use them. However, interfaces are very cool, and anyone who does OOP in PHP should know about them.

To start, what is an interface? An interface is a collection of completely abstract methods. Interfaces do not contain any of the innerworkings of the application; instead, they serve the sole purpose in setting a structure for the objects that implement them. All of their methods must be public. Here is a sample interface:

<?php interface DatabaseI { public function __construct(); public function connect(); public function query(); } [/sourcecode] That doesn't look very interesting at all, and it's not, until we start getting into <a href="http://us2.php.net/manual/en/language.oop5.typehinting.php">type hinting</a> and using <a href="http://us2.php.net/manual/en/language.operators.type.php">instanceof</a> in PHP 5. This is where the power of interfaces comes into play. As a developer, I've often wished there was a way to know that an object - any object - had implemented certain methods. With type hinting and the instanceof operator, it is now possible to determine whether or not an object has those methods, and interfaces make this even easier. Take for example: class withoutTypeHinting { public function __construct($databaseO) { if(method_exists('connect') { $databaseO->connect(); } } } // Now let's use typehinting from our previous example class withTypeHinting { public function __construct(DatabaseI $databaseO) { $databaseO->connect(); } }

What’s the difference there? In the first example, we’re hoping that the method exists so that we can call it. We’ll have to throw an exception or do something if the connection doesn’t actually exist. But in the second example, we’re demanding an object that has implemented the methods in DatabaseI. We know that these methods must have been implemented, because we’re getting an instantiated object. So the method must exist.

Interfaces make it much easier to predict what methods will be available, and also to ensure that subclasses still conform to some semblance of the structure you’ve defined.

Interfaces are not without their drawbacks. One huge drawback of interfaces is that you must implement them precisely as they are defined; that is, because our __construct() method contained no arguments, you must either make your __construct() argument contain no arguments or set each argument to a value (e.g. __construct($a = true, $b = false); // etc). When defining an abstract class, and abstract methods, the rules of inheritance apply, making it possible to redefine the argument list. Also, because you have not defined anything but the method signature, you have no way of forcing it to return a particular type. Finally, you may not build an interface containing protected methods; you must use an abstract class for this.

Still, interfaces rock. They allow you to enforce the type of object and the methods that must be defined, and with type hinting you can always feel confident that a method is implemented, regardless of how that interface is extended.

Frustrated with your company’s development practices? You don't have to be! No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist. Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."

Great! We'll be updating you soon on best practices for your team!

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP