Abstraction de classes
While a subclass may implement an interface by extending an abstract class that implements the interface, I question whether it is good design to to do so. Here's what I would suggest while taking the liberty of modifying the above weather/wet model:
<?php
interface water
{
public function makeItWet();
}
/**
* abstract class implements water but defines makeItWet
* in the most general way to allow child class to
* provide specificity
**/
abstract class weather implements water
{
private $cloudy;
public function makeItWet(){}
abstract public function start();
abstract public function getCloudy();
abstract public function setCloudy();
}
class rain extends weather {
private $cloudy;
public function start() {
return "Here's some weather. ";
}
public function makeItWet() {
return 'it is raining cats and dogs today.';
}
public function getCloudy() {
return $this->cloudy;
}
public function setCloudy($bln=false) {
$this->cloudy = $bln;
}
}
$a = new rain();
echo $a->start();
$a->setCloudy(true);
if ($a->getCloudy()) {
echo 'It is a cloudy day and ';
}
echo $a->makeItWet();
?>
Interfaces
Les interfaces objet permettent de créer du code qui spécifie quelles méthodes une classe doit implémenter.
Les interfaces sont définies en utilisant le mot-clé interface, de la même façon qu'une classe standard mais sans aucun contenu de méthode.
Toutes les méthodes déclarées dans une interface doivent être publiques.
implements
Pour implémenter une interface, l'opérateur implements est utilisé. Toutes les méthodes de l'interface doivent être implémentées dans une classe ; si ce n'est pas le cas, une erreur fatale sera émise. Les classes peuvent implémenter plus d'une interface en séparant chaque interface par une virgule.
Note: Une classe ne peut implémenter deux interfaces qui partagent des noms de fonctions, puisque cela causerait une ambiguïté.
Exemples
Exemple #1 Exemple d'interface
<?php
// Declaration de l'interface 'iTemplate'
interface iTemplate
{
public function setVariable($name, $var);
public function getHtml($template);
}
// Implémentation de l'interface
// Ceci va fonctionner
class Template implements iTemplate
{
private $vars = array();
public function setVariable($name, $var)
{
$this->vars[$name] = $var;
}
public function getHtml($template)
{
foreach($this->vars as $name => $value) {
$template = str_replace('{' . $name . '}', $value, $template);
}
return $template;
}
}
// Ceci ne fonctionnera pas
// Fatal error: Class BadTemplate contains 1 abstract methods
// and must therefore be declared abstract (iTemplate::getHtml)
class BadTemplate implements iTemplate
{
private $vars = array();
public function setVariable($name, $var)
{
$this->vars[$name] = $var;
}
}
?>
Voir aussi l'opérateur instanceof.
add a note
User Contributed NotesInterfaces
mehea
30-Jul-2008 09:55
30-Jul-2008 09:55
logik at centrum dot cz
18-Jul-2008 12:17
18-Jul-2008 12:17
Makes them useles a bit. I give an example:
I have a class that enumerate (so implements iterator) a interface that has method key() that returns key for the enumerated object.
I cannot implement iterator, that enumerates the objects by itself (so current() returns this), because of collision of method key(). But it's not collision - the key in the iterator and the key in the enumerated object has the same meaning and allways returns same values.
(Common example of this iterator is iterator, that reads from database - make a special object for each row is waste of time).
Yes - there are workarounds - e.g. rewrite the code so current don't return this - but it's in some cases waste of processor time.
Or I can rename the method key in enumerated object - but why should I wrote the same method twice? It's either waste of time (if the function key is simply duplicated) or waste of time (if the renamed key calls original key).
Well, the right, clear way there would be to redefine interface iterator -- move the method key to the ancestor of iterator, and makes the ancestor ancestor of enumerated interface too. But it's (with built-in interfaces) impossible too.
harryjry at yahoo dot com
11-Jun-2008 12:29
11-Jun-2008 12:29
The structure I am working with has a lot of inheritance going on, but not all methods are specified in one place. I needed a way to make sure an interface would be used, but that the method(s) defined in the interface are defined somewhere.
As such, I learned that the parent can define the interface's methods, and then the children can override that method at will without having to worry about the interface.
To expand on nrg1981's example, the following is possible:
<?php
interface water
{
public function makeItWet();
}
class weather
{
public function makeItWet()
{
return 'it may or may not be wet';
}
public function start()
{
return 'Here is some weather';
}
}
class rain extends weather implements water
{
public function makeItWet()
{
return 'It is wet';
}
}
class thunder extends weather implements water
{
}
$a = new rain();
echo $a->start() . "\n";
echo $a->makeItWet() . "\n";
$a = new thunder();
echo $a->start() . "\n";
echo $a->makeItWet() . "\n";
?>
kaisershahid at gmail dot com
07-Apr-2008 03:41
07-Apr-2008 03:41
php at wallbash dot com's comment of "It's important to note this because it is very unexpected behavior and renders many common Interface completly useless" doesn't make sense.
the idea of the interface is to force objects that aren't related to be reused in a common way. without them, to force that requirement, all objects that need those methods implemented would have to be descended from a base class that's known to have those methods. that's clearly not a smart idea if these objects aren't actually related.
one example (that i'm currently working on) is a background service that pulls information down from different content providers. i have a transport and i have an import. for both, what actually happens in the background is different from provider to provider, but since i'm implementing a transport & import interface, i only need to write code once, because i know exactly the what methods will be implemented to get the job done. then, i just have a config file that loads the class dynamically. i don't need something like
if ( $provider == "some company" )
{
// use this set of code
}
elseif ( $provider == "another company" )
{
// use this other set of code
}
instead, i can do:
foreach ( $providers as $provider => $info )
{
$_transport = $info['transportObject'];
$transport = new $_transport();
$_import = $info['importObject'];
$import = new $_import();
$transport->setImporter( $import );
$transport->retrieve();
}
it is expected behavior that when a class implements two interfaces that share one or more method names, an error is thrown, because interfaces don't relate to each other. if you want that sort of inferred behavior (i.e. A and B are different except for these shared methods), stick to [abstract] classes.
it sucks that interface methods might collide for some common types of tasks (get(), set(), etc.), so knowing that, design your interfaces with more unique method names.
michael dot martinek at gmail dot com
04-Jan-2008 06:18
04-Jan-2008 06:18
In regards to what Hayley Watson is writing:
The "interface" is a method of enforcing that anyone who implements it must include all the functions declared in the interface. This is an abstraction method, since you cannot just declare a base class and do something like "public abstract function myTest();" and later on extend that class.
If you don't override the default value in a parameter list, it's assumed that the default value was received by time you have any control to read or relay the value on again. There should be no problem in having all or none of your parameters in an interface having a default value, as the value is "auto-filled" if not explicitly provided.
I just came across interfaces in PHP.. but I use them quite a bit in Java and Delphi. Currently building different DB wrappers, but all must enforce common access using a base class.. and also enforce that all of specific routines are implemented.
Docey
12-Nov-2007 01:23
12-Nov-2007 01:23
Another note about default values in interfaces is that an class must implement at least the arguments as in the interface. that is: an implementation may have more arguments but not less if these additional arguments have an default value and thus can be called as declared in the interface.
an litte example:
<?php
interface myInterface{
public function setStuff($id, $name);
}
class MyFirstClass implements myInterface{
public function setStuff($id, $name);
}
class MySecondClass implements myInterface{
public function setStuff($id, $name, $type);
}
class myThirdClass implements myInterface{
public function setStuff($id, $name, $type=0);
}
?>
Here mySecondClass will print an fatal error while myThirdClass is just fine because myThirdClass::setStuff($id, $name); is valid and thus fullfills the interface requirements. an interface declares as set of requirement on how methods can be called and any class implementing an interface thus agrees that is will provide these methods and that they can be called as in the interface. adding additional arguments with default values is thus allowed because it does not violate the agreement that the method can be called as in the interface.
nrg1981 {AT} hotmail {DOT} com
05-Oct-2007 04:48
05-Oct-2007 04:48
In case you would want to, a child class can implement an interface:
<?php
interface water
{
public function makeItWet();
}
class weather
{
public function start()
{
return 'Here is some weather';
}
}
class rain extends weather implements water
{
public function makeItWet()
{
return 'It is wet';
}
}
$a = new rain();
echo $a->start();
echo $a->makeItWet();
?>
Hayley Watson
21-Sep-2007 01:42
21-Sep-2007 01:42
If it's not already obvious, it's worth noticing that the parameters in the interface's method declaration do not have to have the same names as those in any of its implementations.
More significantly, default argument values may be supplied for interface method parameters, and they have to be if you want to use default argument values in the implemented classes:
<?php
interface isStuffable
{
public function getStuffed($ratio=0.5);
}
class Turkey implements isStuffable
{
public function getStuffed($stuffing=1)
{
// ....
}
}
?>
Note that not only do the parameters have different names ($ratio and $stuffing), but their default values are free to be different as well. There doesn't seem to be any purpose to the interface's default argument value except as a dummy placeholder to show that there is a default (a class implementing isStuffable will not be able to implement methods with the signatures getStuffed(), getStuffed($a), or getStuffed($a,$b)).
Hayley Watson
21-Sep-2007 08:34
21-Sep-2007 08:34
On an incidental note, it is not necessary for the implementation of an interface method to use the same variable names for its parameters that were used in the interface declaration.
More significantly, your interface method declarations can include default argument values. If you do, you must specify their implementations with default arguments, too. Just like the parameter names, the default argument values do not need to be the same. In fact, there doesn't seem to be any functionality to the one in the interface declaration at all beyond the fact that it is there.
<?php
interface isStuffed {
public function getStuff($something=17);
}
class oof implements isStuffed {
public function getStuff($a=42) {
return $a;
}
}
$oof = new oof;
echo $oof->getStuff();
?>
Implementations that try to declare the method as getStuff(), getStuff($a), or getStuff($a,$b) will all trigger a fatal error.
php at wallbash dot com
05-Sep-2007 05:39
05-Sep-2007 05:39
Please note that the sentence "Note: A class cannot implement two interfaces that share function names, since it would cause ambiguity." _really_ means that it is not possible to do something like:
<?php
interface IA {
public function a();
}
interface IB {
public function a();
}
class Test implements IA, IB {
public function a() {
echo "a";
}
}
$o = new Test();
$o->a();
?>
lead to:
PHP Fatal error: Can't inherit abstract function IB::a() (previously declared abstract in IA)
It's important to note this because it is very unexpected behavior and renders many common Interface completly useless.
zedd at fadingtwilight dot net
05-Jul-2007 07:42
05-Jul-2007 07:42
Regarding my previous note (04-Jul-2007 9:01):
I noticed a minor but critical mistake in my explanation. After the link to the PHP manual page on class abstraction, I stated:
"So by definition, you may only overload non-abstract methods."
This is incorrect. This should read:
"So by definition, you may only override non-abstract methods."
Sorry for any confusion.
zedd at fadingtwilight dot net
05-Jul-2007 07:01
05-Jul-2007 07:01
prometheus at php-sparcle:
Your code fails because you're effectively trying to do this:
<?php
abstract class IFoo
{
abstract public function Foo();
}
abstract class IBar extends IFoo
{
// Fails; abstract method IFoo::Foo() must be defined in child and must match parent's definition
abstract public function Foo($bar);
}
?>
By definition, all methods in an interface are abstract. So the above code segment is equivalent to your interface definitions and results in the same error. Why? Let's have a look at the PHP manual. From the second paragraph on class abstraction:
"When inheriting from an abstract class, all methods marked abstract in the parent's class declaration must be defined by the child;"
http://www.php.net/manual/en/language.oop5.abstract.php
So by definition, you may only overload non-abstract methods.
For example:
<?php
abstract class IFoo
{
public function Foo()
{
// do something...
}
}
abstract class IBar extends IFoo
{
public function Foo($bar)
{
// do something else...
}
}
?>
This can't be directly replicated with interfaces since you can't implement methods inside of an interface. They can only be implemented in a class or an abstract class.
If you must use interfaces, the following accomplishes the same thing, but with two separate method names:
<?php
interface IFoo
{
public function Foo();
}
interface IBar extends IFoo
{
public function Bar($bar);
}
class FooBar implements IBar
{
public function Foo()
{
// do something...
}
public function Bar($bar)
{
// do something else...
}
}
?>
If both methods need the same name, then you'll have to use non-abstract methods. In this case, interfaces aren't the right tool for the job. You'll want to use abstract classes (or just regular classes).
Maikel
13-Jan-2007 01:07
13-Jan-2007 01:07
if you want to implement an interface and in addition to use inheritance, first it uses “extends” and then “implements” example:
<?php
class MyChildClass extends MyParentClass implements MyInterface
{
// definition
}
?>
Chris AT w3style DOT co.uk
07-Dec-2006 03:25
07-Dec-2006 03:25
Note that you can extend interfaces with other interfaces since under-the-hood they are just abstract classes:
<?php
interface Foo {
public function doFoo();
}
interface Bar extends Foo {
public function doBar();
}
class Zip implements Bar {
public function doFoo() {
echo "Foo";
}
public function doBar() {
echo "Bar";
}
}
$zip = new Zip();
$zip->doFoo();
$zip->doBar();
?>
This is quite useful when you're using interfaces for identity more than the rigidity it places upon an API. You can get the same result by implementing multiple interfaces.
An example of where I've used this in the past is with EventListener objects ala Java's Swing UI. Some listeners are effectively the same thing but happen at different times therefore we can keep the same API but change the naming for clarity.
marasek AT telton POINT de
07-Sep-2006 04:01
07-Sep-2006 04:01
What is not mentioned in the manual is that you can use "self" to force object hinting on a method of the implementing class:
Consider the following interface:
<?php
interface Comparable
{function compare(self $compare);}
?>
Which is then implemented:
<?php
class String implements Comparable
{
private $string;
function __construct($string)
{$this->string = $string;}
function compare(self $compare)
{return $this->string == $compare->string;}
}
class Integer implements Comparable
{
private $integer;
function __construct($int)
{$this->integer = $int;}
function compare(self $compare)
{return $this->integer == $compare->integer;}
}
?>
Comparing Integer with String will result in a fatal error, as it is not an instance of the same class:
<?php
$first_int = new Integer(3);
$second_int = new Integer(3);
$first_string = new String("foo");
$second_string = new String("bar");
var_dump($first_int->compare($second_int)); // bool(true)
var_dump($first_string->compare($second_string)); // bool(false)
var_dump($first_string->compare($second_int)); // Fatal Error
?>
vbolshov at rbc dot ru
10-Aug-2006 12:34
10-Aug-2006 12:34
Consider the following:
[vbolshov@localhost tmp]$ cat t.php
<?php
error_reporting(E_ALL | E_STRICT);
interface i {
function f($arg);
}
class c implements i {
function f($arg, $arg2 = null)
{
}
}
?>
[vbolshov@localhost tmp]$ php t.php
[vbolshov@localhost tmp]$
PHP doesn't generate a Fatal Error in this case, although the method declaration in the class differs from that in the interface. This situation doesn't seem good to me: I'd prefer classes being strictly bound to their interfaces.
spiritus.canis at gmail dot com
25-Oct-2005 08:45
25-Oct-2005 08:45
Regarding the example by cyrille.berliat:
This is not a problem and is consistent with other languages. You'd just want to use inheritance like so:
<?php
class AbstractClass {
public function __ToString ( ) { return 'Here I am'; }
}
class DescendantClass extends AbstractClass {}
interface MyInterface {
public function Hello ( AbstractClass $obj );
}
class MyClassOne implements MyInterface {
public function Hello ( AbstractClass $obj ) {
echo $obj;
}
} // Will work as Interface Satisfied
$myDC = new DescendantClass() ;
MyClassOne::Hello( $myDC ) ;
?>
cyrille.berliat[no spam]free.fr
17-Oct-2005 12:29
17-Oct-2005 12:29
Interfaces and Type Hinting can be used but not with Inherintance in the same time :
<?
class AbstractClass
{
public function __ToString ( ) { return 'Here I\'m I'; }
}
class DescendantClass extends AbstractClass
{
}
interface MyI
{
public function Hello ( AbstractClass $obj );
}
class MyClassOne implements MyI
{
public function Hello ( AbstractClass $obj )
{
echo $obj;
}
} // Will work as Interface Satisfied
class MyClassTwo implements MyI
{
public function Hello ( DescendantClass $obj )
{
echo $obj;
}
} // Will output a fatal error because Interfaces don't support Inherintance in TypeHinting
//Fatal error: Declaration of MyClassTwo::hello() must be compatible with that of MyI::hello()
?>
Something a little bit bad in PHP 5.0.4 :)
darealremco at msn dot com
02-Oct-2005 10:53
02-Oct-2005 10:53
To two notes below: There is one situation where classes and interfaces can be used interchangeably. In function definitions you can define parameter types to be classes or interfaces. If this was not so then there would not be much use for interfaces at all.
warhog at warhog dot net
11-Aug-2005 06:35
11-Aug-2005 06:35
on the post below:
An interface is in fact the same like an abstract class containing abstract methods, that's why interfaces share the same namespace as classes and why therefore "real" classes cannot have the same name as interfaces.
marcus at synchromedia dot co dot uk
28-Jul-2005 02:11
28-Jul-2005 02:11
Classes and interface names share a common name space, so you can't have a class and an interface with the same name, even though the two can never be used ambiguously (i.e. there are no circumstances in which a class and an interface can be used interchangeably). e.g. this will not work:
interface foo {
public function bling();
}
class foo implements foo {
public function bling() {
}
}
You will get a 'Cannot redeclare class' error, even though it's only been declared as a class once.
tobias_demuth at web dot de
05-May-2005 12:21
05-May-2005 12:21
The statement, that you have to implement _all_ methods of an interface has not to be taken that seriously, at least if you declare an abstract class and want to force the inheriting subclasses to implement the interface.
Just leave out all methods that should be implemented by the subclasses. But never write something like this:
<?php
interface Foo {
function bar();
}
abstract class FooBar implements Foo {
abstract function bar(); // just for making clear, that this
// method has to be implemented
}
?>
This will end up with the following error-message:
Fatal error: Can't inherit abstract function Foo::bar() (previously declared abstract in FooBar) in path/to/file on line anylinenumber
erik dot zoltan at msn dot com
25-Feb-2005 08:43
25-Feb-2005 08:43
When should you use interfaces? What are they good for?
Here are two examples.
1. Interfaces are an excellent way to implement reusability.
You can create a general interface for a number of situations
(such as a save to/load from disk interface.) You can then
implement the interface in a variety of different ways (e.g. for
formats such as tab delimited ASCII, XML and a database.)
You can write code that asks the object to "save itself to
disk" without having to worry what that means for the object
in question. One object might save itself to the database,
another to an XML and you can change this behavior over
time without having to rewrite the calling code.
This allows you to write reusable calling code that can work
for any number of different objects -- you don't need to know
what kind of object it is, as long as it obeys the common
interface.
2. Interfaces can also promote gradual evolution. On a
recent project I had some very complicated work to do and I
didn't know how to implement it. I could think of a "basic"
implementation but I knew I would have to change it later.
So I created interfaces in each of these cases, and created
at least one "basic" implementation of the interface that
was "good enough for now" even though I knew it would have
to change later.
When I came back to make the changes, I was able to create
some new implementations of these interfaces that added the
extra features I needed. Some of my classes still used
the "basic" implementations, but others needed the
specialized ones. I was able to add the new features to the
objects themselves without rewriting the calling code in most
cases. It was easy to evolve my code in this way because
the changes were mostly isolated -- they didn't spread all
over the place like you might expect.
mat.wilmots (at) wanadoo (dot) fr
20-Jan-2005 04:22
20-Jan-2005 04:22
interfaces support multiple inheritance
<?php
interface SQL_Result extends SeekableIterator, Countable
{
// new stuff
}
abstract class SQL_Result_Common
{
// just because that's what one would do in reality, generic implementation
}
class SQL_Result_mysql extends SQL_Result_Common implements SQL_Result
{
// actual implementation
}
?>
This code raises a fatal error because SQL_Result_mysql doesn't implement the abstract methods of SeekableIterator (6) + Countable (1)
russ dot collier at gmail dot com
28-Nov-2004 08:24
28-Nov-2004 08:24
You can also specify class constants in interfaces as well (similar to specifying 'public static final' fields in Java interfaces):
<?php
interface FooBar
{
const SOME_CONSTANT = 'I am an interface constant';
public function doStuff();
}
?>
Then you can access the constant by referring to the interface name, or an implementing class, (again similar to Java) e.g.:
<?php
class Baz implements FooBar
{
//....
}
print Baz::SOME_CONSTANT;
print FooBar::SOME_CONSTANT;
?>
Both of the last print statements will output the same thing: the value of FooBar::SOME_CONSTANT