Sorry, pal, but this is ridiculous.
This test of yours is going completely against the whole concept of OOP and interfaces.
BerislavLopac is right if not a bit harsh. Indeed if interfaces are slower than abstract classes that is a bit strange, but interfaces provide better OOP in PHP than do abstract classes. If you really care about time, you should use abstract (according to those results), but if you care about readability and conformity with OOP, use interfaces.
I didn’t mean that the results are ridiculous, I meant that the idea of testing what he did is ridiculous. It’s as if you ride a bus from one point to another while constantly walking inside the bus, and then you compare walking with driving…
Sorry, I don’t understand that analogy. Please enlighten me! 
For the validity of the test, aren’t all benchmarks taking it to the extreme? 
I ran it a few times with just a few methods implemented, and the results were very similar (if different at all).
True, if you want to conform to the “rules,” use interfaces when appropiate. For a slight speed increase, abstract is the way to go. I’m sure there are some major differences between interfaces and abstracts in other languages, but in PHP, interfaces are essentially abstract classes with limited functionality.
The results are really odd though for PHP. It clearly says that there is some technical difference, but I don’t know what. Odd!
The old argument of performance rarely make any sense, yet is always brought up. You know that objects are slower to use than strictly procedural code - Would you use that as an argument for not writing OOP code ?
No. PHP has single inheritance. (and thank GOD for that)
Sorry, I didn’t intend to start an argument! I was just sharing some interesting results that I found. My hypothesis was that interfaces were faster, but that isn’t the case if my test is accurate.
By this,
PHP has single inheritance.
do you mean “Abstract classes support single inheritance while interfaces support multiple”?
All in good intention and interested in learning more,
Check this thread
Also another example to show you what an interface does
interface iOpenable{
abstract function open();
abstract function close();
}
<?php
require_once('inc.openable.php');
class Door implements iOpenable{
private $_locked = false;
public function open(){
if($this->_locked){
print("Door is locked!");
}else{
print("Opened door!")
}
}
public function close(){
print("BAF!");
}
//etc
}
class Jar implements iOpenable{
private $_contents;
public function __construct($contents){
$this->_contents = $contents
}
public function open(){
print("Opened Jar!");
}
public function close(){
print("Closed Jar!");
}
}
function openSomething(iOpenable $oOpenable){
$oOpenable->open();
}
$oDoor = new Door();
$oJar = new Jar("milk");
openSomething($oDoor);
openSomething($oJar);
?>
Example you don’t need interfaces to write a complete framework
http://www.sitepoint.com/forums/showthread.php?t=285844
(just use base classes as abstraction)
B.t.w, i Don’t think PHP Interfaces are ready yet, no namespaces will result in non-unique context’s where interface are “concrete” contracts between unique context’s imho.
Still PHP’s Interfaces are weird, they alow you to specify abstract method declarations, loose types, abstration inherits interface… all no good when it comes to understanding the use of interfaces…
just my 2c
You don’t “inherit” an interface since there’s no functionality to inherit. Instead, you “realise” or “implement” it (implementing expected methods vs. inheriting existing ones).
PHP supports single class inheritance and multiple interface implementation.
You Inherit is, oh yes you do, you inherit a “type” exacly…
:goof:
“PHP supports single class inheritance and multiple interface implementation.”
Well, support is a big word, it’s more likely the zend team just stuffed some routines in the core so we could use something that’s likely to act as a single interface unit, but it’s not realy succesfull hence why we don’t hear a lot of zend lately, but then again maybe there up to something…
(start writing again from scratch) 
IMO type is implemented, you don’t inherit squad by using interfaces.
Fair enough. Just to make it clear - I didn’t intend to patronize you and nor do I think any of the other posters were. I’m simply saying that your premise is wrong - It doesn’t matter which is faster, since speed shouldn’t be a decisive factor. (Unless of course the difference is very severe, but this isn’t the case)
Yes and no. You can only inherit once, but you can implement multiple interfaces.
I came to use interfaces as a way to ensure that classes have all the must-have functions. No more no less, at least not in PHP. I know, it’s kind of limiting.
As I have argued before, Interfaces in PHP make a great documentation, and that’s it. They have no practical purpose whatesoever. 
I’m just reading a book called “Holub on Patterns” (Java based code examples but I think the theory he talks about still applies).
Chapter 2: “Programming with Interfaces and a Few Creational Patterns”
Section: “The Fragile-Base-Class Problem”
He argues that by extending a base class it becomes fragile because other derived implementations become obscured as programmers extend the interface defined by the base class. Whereas interfaces do not obscure the interface with implementation.
I don’t think I’m communicating his message very well, perhaps an example from the book will help.
(The code here has been interpreted from a Java based example.)
class ArrayList
{
// class implementation
function add() { /*... */ }
function remove() { /*... */ }
function clear() { /*... */ }
}
class Stack extends ArrayList
{
private topOfStack = 0;
public push($article)
{
$this->add($this->topOfStack++, $article);
}
public pop()
{
$this->remove(--$this->topOfStack);
}
public pushMany($articles)
{
foreach ($articles as $article) {
$this->push($article);
}
}
}
$stack = new Stack();
$stack->push("1");
$stack->push("2");
$stack->clear();
$stack->push("3");
…since the base class doesn’t know anything about the index of the item at the top of the stack (topOfStack), the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the current value of the topOfStack), so the stack effectively has three elements on it, the bottom two of which are garbage.
One (hideously bad) solution to the inheriting-undesirable-methods problem is for Stack to override all the methods of ArrayList that can modify the state of the array to manipulate the stack pointer. This is a lot of work, though, and doesn’t handle problems such as adding a method like clear() to the base class after you’ve written the derived class.
Quote by Allen Holub from “Holub on Patterns” (page 41 to 42).
He goes onto to say that the programmer shouldn’t exclude the use of base classes, which are very powerful, but carefully consider their use. They can be extremely useful to share functionality but can also cause code like the example described above. He then describes how interfaces negate this and other problems at the cost of losing the shared implementation from the base class.
[edit] Here’s a suggested solution using interfaces
interface Stack
{
public function push($article);
public function pop();
public function pushMany($articles);
public function size();
}
class SimpleStack implements Stack
{
private $topOfStack;
private $arrayStack;
function __construct()
{
$this->arrayStack = new ArrayStack();
}
function push($article)
{
$this->arrayStack->add($this->topOfStack++, $article);
}
// you can work out the rest...
}
Hope that helps someone.
Luke
Basically one should always keep in mind two things:
- OOP is all about types.
- Types are all about behavior.
This also tell us that classes are a foreign entity in OOP, probably introduced in C++ to ease transition from C. Interfaces – as a theoretical, not a syntactical concept – are what defines a type, and a class is really just a convenience allowing us to define implementation. In reality we don’t need classes, nor interfaces as formal entities, to have an OOP language.
I think we just got Javascript.
- There is not One True Way