Dérive d'utilisation des interfaces

[christouphe]

Bonjour / Bonsoir à tous,

je me pose quelques question concernant les interfaces surtout en PHP puisque c'est dans ce langage que je développe en ce moment.

J'ai conçu mon application (enfin essayé) en couches:

• Accès base de données (PDO)
  
• les DAO <=> objets de l'application modéllisé depuis la base de données
  
• des managers de type (User, Object...)
  
• des fabriques d'objets (User, Object...)
  

Comme mes fabriques possèdent 90% de leurs méthodes en commun, je les ai implémentées à partir d'une interface commune, ce qui m'a semblé logique.

J'arrive à un point où je peux aussi appliquer cette méthode aux managers alors voilà ma question:

Hors cadre d'organisation du code et de la conception, j'ai remarqué que les interface amenait au moins deux avancées:

• Une possibilité de multiple héritage, même si cela n'est pas réellement de l'héritage
  
• Une normalisation de la structure du code pour le travail en équipe, par exemple un manager contient telle et telle méthode "obligatoire"
  

J'aurai voulu avoir votre avis sur la deuxième idée, et même l'ensemble hein, ne soyons pas radins :p.

Question supplémentaire: est-ce que l'un d'entre vous sait comment une méthode d'objet connaît la classe (méthode) appelante ?

Merci de m'avoir lu, onne journée/soirée.

[Ter Rowan]

• Une possibilité de multiple héritage, même si cela n'est pas réellement de l'héritage
  
• Une normalisation de la structure du code pour le travail en équipe, par exemple un manager contient telle et telle méthode "obligatoire"
  

J'aurai voulu avoir votre avis sur la deuxième idée, et même l'ensemble hein, ne soyons pas radins :p.

bah pour moi le tout = la deuxième puisque l'interface ne génère, en php, rien en dehors de contrôle du code. Le même code sans les interfaces fonctionnera. Par contre ça apporte effectivement une normalisation pour le travail en équipe mais aussi pour le travail individuel, quand on travaille dans des périodes morcellées ou encore pour la maintenance (plus facile de savoir qu on doit "envoyer" des objets respectant telles interface si c'est écrit dans le code)

Question supplémentaire: est-ce que l'un d'entre vous sait comment une méthode d'objet connaît la classe (méthode) appelante ?

pas sûr d'avoir bien compris ce que tu voulais donc risque de tomber à côté de la plaque mais avec :

Code PHP :

<?php 

get_class($this) 

[christouphe]

Merci pour les réponses, pour la deuxième en fait c'est plutôt comme cela:

Code PHP :

<?php 

class A {

    //...

    public funtion toto($var1,$laMethodeAppelante) {

        if ($laMethodeAppelante) {

            echo '<br>'.$var1;

        } else {

            echo 'Pas le/la bon/ne objet/méthode appelant';

        }

}



class B {

    //

    public function appelleTotoDeA($oA) {

        $oA -> toto("LOL",$laMethodeAppelante);//ici comment dire un objet B ou la méthode appelleTotoDeA

    }

}



$oA = new A();

$oB = new B();



B -> appelleTotoDeA($oA); //afficherai  LOL 

[Shao]

Selon moi, l'utilisation d'interfaces est beaucoup plus puissant qu'un simple héritage.

Quand on implémente une interface, on développe ce que l'on veut au sein de sa classe (même si par composition ou par délégation, il est possible bien entendu de regrouper des comportements), tandis qu'avec un simple héritage, on peut se retrouver avec des méthodes qui nous intéressent pas au sein de la classe mère.

Cela permet également de modulariser son code. Comme tu l'as si bien dit, on peut implémenter plusieurs interfaces au sein d'une classe. Du coup il assez simple de découper son code en petits morceaux que l'on va greffer dans notre projet (dans le cas de PHP c'est moins flagrant, mais je t'assure que pour d'autres langages comme le Java, le C++ ou même l'ActionScript, c'est super utile). A titre d'exemple, si je développe une librairie de composants graphiques, je peux définir que mes composants sont déplaçables (IMovable), et également que je peux modifier leurs tailles (IResizable) : C'est plus intéressant qu'une classe Component qui contient l'implémentation des deux.

Et comme tu l'as dit à la fin, cela permet d'imposer une structure afin qu'une équipe, ou un ensemble de personnes, respectent un ensemble de règles quand ils développent avec ton code pour une meilleure lisibilité et une plus grande compréhension. Et s'il y a des nouvelles choses à développer, il suffit de rajouter les interfaces correspondantes, et de greffer petit à petit les nouveaux morceaux de code.