Discussion :

[mapmip]

Bonjour,

en matière de classe, je suppose qu'une méthode abstraite ne peut pas se trouver dans une classe concrète
seulement dans une classe abstraite.

Dans quel cas avez-vous besoin de mettre la méthode abstraite dans une classe abstraite plutot que dans une interface ?

Merci d'avance

[grunk]

Une explication assez claire est dispo dans un des commentaires de la doc : http://php.net/manual/fr/language.oo...ract.php#82111

On pourrait résumer ainsi :

class X implements Y { } X accepte de parler le langage de Y avec ton code
class X extends Y { } X va compléter la classe partielle Y

Si tu es le seul à utiliser ton code , les interface n'ont pas vraiment lieu d'être.

[rawsrc]

Salut,

en matière de classe, je suppose qu'une méthode abstraite ne peut pas se trouver dans une classe concrète
seulement dans une classe abstraite.

Tout à fait exact. Dans d'autres langages, tu peux retrouver une méthode abstraite dans l'implémentation d'une classe concrète mais dans ce cas, implicitement la classe est notée abstraite par l'interpréteur.

La nuance entre une méthode abstraite et une interface est fine mais elle existe. Petit rappel :
La méthode abstraite correspond à une fonctionnalité qui doit être implémentée dans la ou les classes dérivées. On reste au stade de la fonctionnalité n'identifiant pas de manière particulière une classe, alors qu'une interface relève plus du contrat que doit remplir une classe dans une architecture donnée. Un contrat peut nécessiter plusieurs fonctions pour être rempli et fournit en plus un type à la classe qui l'implémente.

Par exemple, si tu prends l'interface \Iterator, cette dernière nécessite d'implémenter 5 fonctions pour que le contrat soit rempli :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Iterator  extends Traversable  {
 
/* Methods */
abstract public mixed current ( void )
abstract public scalar key ( void )
abstract public void next ( void )
abstract public void rewind ( void )
abstract public boolean valid ( void )
}

Tu noteras que l'implémentation est obligatoire par l'utilisation du caractère abstract de chaque fonctionnalité, ainsi si tu fais quelque chose dans ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class Foo
implements Iterator
{
    public function bar()
    {
        return 'bar';
    }
}

tu ramasseras une erreur fatale

Fatal error: Class Foo contains 5 abstract methods and must therefore be declared abstract or implement the remaining methods (Iterator::current, Iterator::next, Iterator::key, ...)

L'intérêt de l'interface est qu'en POO tu peux ainsi être certain que l'objet manipulé remplit un contrat donné : public function bar(Iterator $p) { ... }, tu sais sans ambiguïté que le paramètre $p est traversable avec foreach.

Là où une classe peut remplir plusieurs contrats (implements InterfaceA, InterfaceB, ..., une classe dérivée ne peut hériter que d'une seule classe parente (abstraite ou pas).

Pour conclure : la méthode abstraite dans une classe abstraite sert à t'assurer que le code de la méthode en question sera obligatoirement adapté à l'environnement de la classe dérivée alors que l'interface sert à t'assurer que ta classe aura une aptitude particulière et sera identifiable comme telle.

Ce genre de problématique est directement lié à la définition d'une architecture pour des éléments plus ou moins abstraits dans la création de composants réutilisables et interdépendants.
En dehors de ce genre d'objectif, il faut savoir rester léger

[mapmip]

Ce qui est bien aussi c'est qu'on peut appeller statiquement une méthode se trouvant dans une classe abstraite

[mapmip]

et quand une classe abstraite implémente une interface,
est-ce au niveau de la classe abstraite d'implémenter les functions de l'interface
ou plutot au niveau de la classe concrète qui hérite de la classe abstraite mère ?

[rawsrc]

Au choix.

La classe abstraite peut fournir l'implémentation de tout ou partie de l'interface ou laisser le soin à la classe dérivée de la fournir entièrement ou en partie.
L'important c'est que lorsque tu instancies une classe, cette dernière doit obligatoirement remplir toutes les contraintes fournies soit par le caractère abstrait de l'arbre des classes parentes et/ou par l'arbre des interfaces des classes parentes.