Discussion :

[mon_nom_est_personne]

Bonjour a tous,
Je pose cette question juste par curiosite personnelle. Cette question etant: Est-ce que quelqu'un sais pourquoi en php on a choisi d'implemente l'heritage simple et non multiple ? pour faire comme java ? ou il y a eu une longue et complexe discusion comme pour les namespaces ? car je pense que dans la POO actuel, l'importance de l'heritage multiple n'est plus a debattre. Car un diagramme de classe, soit notre beau projet n'est ni plus ni moins qu'un graphe ou une ontologie de ce dernier. Et dans ces deux theories, l'heritage multiple est tout a fait autorise. je prendrais encore l'eternel exemple de la class 'mere' et de la class 'fille', il me semble que dans la nature la class 'fille' a aussi un papa
Qui plus est dans de nombreux langage dont la pertinance n'est plus a prouver comme c++ et lisp l'heritage multiple est possible.

[ThomasR]

Bonjour,

il me semble que dans la nature la class 'fille' a aussi un papa

On peut hériter de deux classes en même temps ?

N'aurais tu pas voulu dire :

il me semble que dans la nature la class 'mere' a aussi une maman

Je ne sais pas exactement pourquoi l'héritage multiple / arborescent n'est pas permis en PHP mais cela ne limite en rien les possibilités. Tu peux facilement contouner ca en utilisant une ou plusieurs interface.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
interface A {
Méthodes_A1();
Méthodes_A2();
}
 
interface B {
Méthodes_B1();
Méthodes_B2();
}
 
class C implements A, B {
}

[lespoches]

Salut !

Il me semble que c'est un peu une hérésie de contourner le problème d'une telle manière me dirant mon ancien prof d'UML. Je sais la réalité de la prod a s'est raison que la raison elle meme n'a pas mais dans je préfère m'en tenir à ma propre experience.

Pourquoi PHP n'a pas choisi de permettre l'héritage multiple, ca c'est une bonne question. Je pense déjà qu'un objet fils héritant de plusieurs père, ca c'est pas bon, pas bon du tout, ca traduit souvent un problème de modélisation. Je m'explique:

Pourquoi avoir un objet fils partageant les méthodes des deux pères ?
Cela signifie que les méthodes des deux pères peuvent être mergé dans un seul objet et eject l'héritage multiple. Que je pense!!!

J'attends qu'on me corrige.
Cordialement
jo

[GoTrUnKo]

Bonjour,

La méthode de ThomasR est surement la plus judicieuse.

Lepoches, je ne suis pas du tout d'accord avec toi, il est très intéressant parfois d'avoir plusieurs "parent" pour un seul "enfant", que ce soit en php, actionScript ou autre c'est parfois très très utile.

De plus, mon prof d'UML me dirait tout le contraire du tiens, il est parfois beaucoup plus judicieux de séparer les traitements en plusieurs classes, il faut penser dans le temps, à l'avenir, à une utilisation futur de ces classes, le but des classes et aussi d'être utiliser dans d'autres programmes car elles ont un traitement et une structure spécifique.

[lespoches]

Lepoches, je ne suis pas du tout d'accord avec toi, il est très intéressant parfois d'avoir plusieurs "parent" pour un seul "enfant", que ce soit en php, actionScript ou autre c'est parfois très très utile.

Peux tu me fournir un exemple stp ?

De plus, mon prof d'UML me dirait tout le contraire du tiens, il est parfois beaucoup plus judicieux de séparer les traitements en plusieurs classes, il faut penser dans le temps, à l'avenir, à une utilisation futur de ces classes, le but des classes et aussi d'être utiliser dans d'autres programmes car elles ont un traitement et une structure spécifique.

Attention a ne pas confondre maintenabilité de ton applicatif et cohérence vis à vis des règles UML.

http://www.iutc3.unicaen.fr/~moranb/...ic2/stat19.htm

Mais encore !

[ThomasR]

Je sais pas si on peut voir çà comme une hérésie puisqu'en fait on ne contourne pas de problèmes, c'est la méthode la plus adaptée pour éviter de coder n classes qui sont censés avoir des méthodes en commun (en PHP du moins).

Je pense que ca doit être compliqué à gérer pour un language interprêté et non compilé comme PHP.

Finalement, je me posais une question sur l'extrait ci-dessous

je prendrais encore l'eternel exemple de la class 'mere' et de la class 'fille', il me semble que dans la nature la class 'fille' a aussi un papa

Au final, quelle serait la différence entre la classe "pere" et la classe "mere". Si on devait représenter çà de manière concrète, Papa et Maman serait une seule et même classe HOMME.

Tu aurais un cas réel où l'utilisation d'un héritage multiple s'appliquerait ? Cà m'intrigue

[lespoches]

je prendrais encore l'eternel exemple de la class 'mere' et de la class 'fille', il me semble que dans la nature la class 'fille' a aussi un papa

Ote moi un doute ! Tu n'est pas en train de confondre héritage et lien relationnel d'appartenance dans un Système d'information

[GoTrUnKo]

Un exemple où l'intérêt de faire appel à deux classes en même temps :

- une classe traitement d'un fichier XML
- une classe qui va gérer des images (audio ou vidéo aussi)
- une classe qui va gérer l'affichage

Il est préférable que l'affichage hérite de la gestion d'un fichier xml et de la gestion des images. Certe on peut tout mettre dans un seul fichier, comme tout d'ailleurs, mais l'intérêt de faire ceci est que je pourrais me servir de la classe gérant le XML dans une autre application, idem pour les images, et l'affichage elle est propre au site internet et donc pas trop utilisable sur une autre application.

A la fin on a donc traitementXml, gestionImages en classe parent pour la classe enfant Affichage.

Ceci est une exemple php par contre, en Action c'est encore pire lorsque l'on doit gérer l'audio, la vidéo, le streaming, et tout le bouzin de ce genre, surtout lorsque l'on utilise ActionScript directement dans un blocnote et non les logiciels permettant de tout faire en quelques cliques ^^'

Au final, quelle serait la différence entre la classe "pere" et la classe "mere". Si on devait représenter çà de manière concrète, Papa et Maman serait une seule et même classe HOMME.

J'aurais plutôt dis la classe "Parent" plutôt que Homme, peut y avoir plusieurs parents (y'en a qui vont voir ailleurs et je dirais "normal" 'bref) mais il est clair qu'entre "pere" et "mere" on ne peut faire une distinction direct pour déterminer qui est qui à ce que je sache :/ sinon c'est que je ne dois pas comprendre pourquoi utiliser "pere" et "mere" alors qu'on peut dire "parent"

[kaymak]

Moi ce que je sais c'est que comme y'à pas d'héritages multiples, ben on ne peut pas faire des diagrammes complètement bizarres qui perdent de sens.
Et cela est plutôt bien vu la niveau moyen des développeurs/concepteurs PHP (sans aucun dédain et en m'incluant dedans).

En plus bon, l'héritage multiple c'est bien dans la théorie, dans la pratique, on travail sur des modèles restreint et la nécessité de l'héritage multiple est d'un coup réduite.
Bien sûr si l'on doit commencer à modéliser la terre entière, alors oui l'héritage multiple à sûrement sa place. mais d'ici là..

enfin bon y'à qu'à voir. Un parent doit t'il donner lieu à une classe Mère et Pere, une classe Homme, une autre mammifère ect ect quand je délire.
On peut aller loin comme cela, sans avoir véritablement besoin dans notre application métier...

[mon_nom_est_personne]

kaymak c'est bien vrai faut aps aller trop loin sinon on va finir avec des class univers etc.. l'exemple du papa et de la maman c'est pour faire une analogie avec le monde relle.
l'exemple ou l'heritage multiple deviens interessant et peut etre si commun c'est un site web.
on va dire que j'ai une class abstrait page qui est un peu la mamam (c'est plus mignon) de toute mes pages. jusque la pas de souci. demain mon site marche bien, et je decide d'avoir des pages proteger par un password. je fait donc devoir completement modifie mon architecture, ma classe page prend du galon, elle est etendu par deux class page_sans_login et page_avec_login qui chacun son etendu par les sous class respectives. Mon apprentissage du php evolue et je decide de me lancer dans une interface admin.je vais donc casser encore une fois mon projet en ajoutant sous page_avec_login une class page_admin.

Resultat, j'ai changer deux fois la structure de mon programme, je suis passe a ^4 de probabilite de bug et je me demande meme quel est la profondeur d'heritage maximal en php.

si j'avais de l'heritage multiple j'aurais commence par le meme schemas, un class mama page et ses fille, on ajoute une classe login qui as toute les propriete de login et mes page proteger par un mot de passe herite des deux. bref, si des bug apparaisse au moins les pages deja existante marche toujours. apres on a juste a mettre une autre classe admin et mes pages admin heritent des 3. mon integration s'est passe sans souci.

[lespoches]

Mauvais exemple que celui d'une page mère et de ses pages filles.
Toute page est une page en soit!
En UML, la classe page a un lien sur elle meme. Ce qui change seulement, c'est son contenu et la tu peux te pencher sur des solutions telles que les moteurs de templates qui te permettent aisément d'implémenter le pattern MVC...

L'héritage multiple n'est pas une bonne pratique (problème de maintenance du code car modèle incohérent) !

[kaymak]

<mode_derive>

kaymak c'est bien vrai faut aps aller trop loin sinon on va finir avec des class univers etc.. l'exemple du papa et de la maman c'est pour faire une analogie avec le monde relle.
l'exemple ou l'heritage multiple deviens interessant et peut etre si commun c'est un site web.
on va dire que j'ai une class abstrait page qui est un peu la mamam (c'est plus mignon) de toute mes pages. jusque la pas de souci. demain mon site marche bien, et je decide d'avoir des pages proteger par un password. je fait donc devoir completement modifie mon architecture, ma classe page prend du galon, elle est etendu par deux class page_sans_login et page_avec_login qui chacun son etendu par les sous class respectives. Mon apprentissage du php evolue et je decide de me lancer dans une interface admin.je vais donc casser encore une fois mon projet en ajoutant sous page_avec_login une class page_admin.

Resultat, j'ai changer deux fois la structure de mon programme, je suis passe a ^4 de probabilite de bug et je me demande meme quel est la profondeur d'heritage maximal en php.

si j'avais de l'heritage multiple j'aurais commence par le meme schemas, un class mama page et ses fille, on ajoute une classe login qui as toute les propriete de login et mes page proteger par un mot de passe herite des deux. bref, si des bug apparaisse au moins les pages deja existante marche toujours. apres on a juste a mettre une autre classe admin et mes pages admin heritent des 3. mon integration s'est passe sans souci.

Ben l'ayant fait, je n'ai pas du tout opter pour l'héritage.
Mais pour une composition. là ou j'appliquerais de l'héritage, voir multiple, c'est sur le type de contenu.
Disons que l'on à un contenu qui peut être une page web, un fichier texte, une ressource xml ect Ici il pourrait y'avoir héritage multiple.
Après, ce contenu à des droits de visibilité, comme on peut avoir des droits d'administration => composition.

En UML, la classe page a un lien sur elle meme.

Sinon sa je n'ai pas compris l'utilité d'une relation sur elle même.
Un répertoire à une liaison sur lui même puisque qu'une instance peut en avoir n autres enfants.

...je me demande meme quel est la profondeur d'heritage maximal en php.

Très bonne question, au pif j'aurais dit infini, selon la capacité du système. A confirmer.
</mode_derive>

L'héritage multiple n'est pas une bonne pratique (problème de maintenance du code car modèle incohérent) !

Ben je suis d'accord avec cela, mais bon en même temps ce sont des langages connus qui l'implémentent et cet état de fait me laisse tout de même songeur sur comment on s'en sert de manière optimum, quand, et, dans la pratique cela fût il vraiment utile et cela à t'il aidé par la suite à gérer des évolutions complexes.
Curiosité qd tu nous tiens.

bye

[lespoches]

Pourquoi PHP n'autorise pas l'héritage multiple !

La réponse paragraphe 4 (langage interprété)

Et moi ma foie, je m'en porte pas plus mal !

[kaymak]

bien joué

[mon_nom_est_personne]

exactement bien vu, merci d'avoir eclairer ma lanterne

[s.n.a.f.u]

En étant intégriste, je pourrais même me demander pourquoi implémenter l'héritage alors que la composition est ce que je préfère utiliser.

[genova]

Désolé de remonter un peu le sujet, je faisais des recherches sur l'héritage multiple et je suis tombé sur cette discussion. Je trouve très dommage que l'héritage multiple ne soit pas intégré à PHP, je vais prendre un exemple simple, avec les classes suivantes (il s'agit d'un système ORM avec jobs / collections) :

• Une classe Job
• Une classe Article
• Une classe JobRecursif
• Une classe JobDynamique

Un Article est un Job, j'ai donc :

Code :

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

class Article extends Job {}

Tout comme j'aurais des dizaines d'autres classes Topic, Media, etc.. qui seront aussi des Job.

Seulement, il se trouve que mon article a aussi la caractéristique d'être récurisf, et dynamique (avec des champs dynamiques). Par conséquent mon Article devrait pouvoir hériter aussi de jobRecursif et de jobDynamique.

En effet, ces fameuses classes jobRecursif et de jobDynamique permettent d'étendre mon système de Job. La plupart de mes classes enfants (Topic, Media, etc..) n'en ont pas besoin. Certaines ont besoin d'être récursives ou dynamiques. Mais mon Article lui a besoin des deux.

Dans la logique, il devrait donc être possible de faire :

Code :

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

class Article extends Job, JobRecursif, JobDynamique {}

afin que Article puisse bénéficier des méthodes dont il a besoin.


Cette absence d'héritage multiple est donc pénible puisque je ne peux pas organiser mon projet de cette façon. A la place je suis obligé d'intégrer de base à ma classe Job les possibilités qu'offrent JobRecursif et JobDynamique, surchargeant ainsi inutilement mon code puisque la majorité des classes qui descendront de Job n'auront pas besoin de tout ce code en plus.


Alors j'ai lu plusieurs fois "les interfaces permettent de contourner ce problème", oui mais comment ?


Pour reprendre mon exemple, si j'applique la fameuse solution de ThomasR sur ce message : http://www.developpez.net/forums/m3792009-2/ voilà donc ce que ça donnerait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
interface JobRecursif
{
  public function getParent();
  public function getChildren();
}
 
interface JobDynamique
{
  public function getDynamicFields();
}
 
class Job
{
  public get() {}
  public set() {}
  (...)
}
 
class Article extends Job implements JobRecursif, JobDynamique
{
  (...)
}

Alors ça me fait une belle jambe cette solution, parce que je suis obligé de mettre le code des méthodes getParent(), getChildren(), getDynamicFields() dans ma classe Article. Quel est l'intérêt de faire ça ? Je vais devoir me trimballer le code de ces méthodes à chacun de mes classes qui implémenteront une (ou les deux) interfaces.

J'ai l'impression que les personnes disant que l'héritage multiple peut être contourner avec les interfaces ne se jamais vraiment poser la question du cas concret. Ou alors je suis à côté de la plaque ? Mais je ne vois pas où, les interfaces permettant seulement de déclarer une liste de méthodes.




Maintenant concernant l'implémentation de l'héritage multiple dans PHP, pour moi il ne se pose aucun problème logique à partir du moment ou les méthodes ont toutes des noms différents (comme dans mon exemple). En soit il s'agit d'un simple "merge" des méthodes, et je pense que PHP aurait pu au moins intégrer ce minimum syndicale, quitte à pondre une erreur en cas de méthode se retrouvant dans "deux classes parents". Après je suis conscient qu'en cas de méthodes ayant le même nom, on tombe sur des problématiques liées à la surcharge, à l'appel des parents, etc.. mais je maintiens que le simple "merge" des méthodes aurait permis beaucoup de chose sans aucune difficulté technique.

PS : l'agrégation ne répond pas non plus à mon problème.

[goodpz]

Il y a des propositions assez avancées concernant des méthodes alternatives au multiple héritage dans php:
Traits: http://wiki.php.net/rfc/traits
Horizontal Reuse: http://wiki.php.net/rfc/horizontalreuse
Il y a fort à parier qu'une future version de php intègre d'une manière ou d'une autre ce genre de features. J'en serais le premier ravis.

[ThomasR]

Bonsoir génova,

Ton post est très interessant tu as bien fait de poster

En fait l'utilisation des interfaces impose simplement une contrainte aux classes, evidemment cela nécessite d'impacter chacunes des modifications dans tous les fichiers où l'interface est implémentée.

Avec certains éditeurs PHP il est facile de synchroniser ces différents fichiers.

On peut encore améliorer ca si on fait hériter la classe Article d'une classe HeritageMultiple, ce qui permettra d'instancier dynamiquement les classes JobRecursif, JobDynamique. Le problème c'est que la classe Article n'hérite pas directement de ces dites-classes et donc qu'il faut créer des fonctions qui font appels aux méthodes des objets JobRecursif et JobDynamic.

Là où çà apporte un intérêt c'est que cela permet de conserver le code métier à un seul endroit et d'éviter de se galérer avec les require. Bref ^^

Code :

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

1
2
3
4
5
6
7
8
 
class HeritageMultiple
{
    function callClass($class_to_call)
    {
        return new $class_to_call();
    }
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
class JobRecursif extends Job
{
   public $children, $parent;
   function getParent(){
       return $this->parent;
   }
 
   function getChildren(){
       return $this->children;
   }   
 
   function addChildren($obj){
       $this->children[] = $obj;
   }
}
 
class JobDynamique extends Job
{
   // [..]
}
 
class Job
{
  // [...]
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Article extends HeritageMultiple
{
    private $jobRecursif;
    function __construct(){
        $this->jobRecursif = parent::callClass('jobRecursif');
        $this->jobRecursif->addChildren(new Article());
    }
 
    function getChildren(){
        return $this->jobRecursif->getChildren();
    }
}

Ca reste malgré tout une alternative un peu bancale...

[goodpz]

Ca reste malgré tout une alternative un peu bancale...

Effectivement Mais on y arrive quand même...

Les interfaces permettent d'avoir un "héritage multiple" par rapport aux types, mais pas par rapport aux implémentations. Les mixins et autres traits (voir mon précédent post) apportent une solution viables sans tomber dans les désavantages du multiple héritage classique.