+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Dérive d'utilisation des interfaces (/showthread.php?tid=4844)
Dérive d'utilisation des interfaces - christouphe - 25-05-2010
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.
RE: Dérive d'utilisation des interfaces - Ter Rowan - 25-05-2010
(25-05-2010, 02:15 PM)christouphe a écrit :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)
- 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
(25-05-2010, 02:15 PM)christouphe a écrit : 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)
RE: Dérive d'utilisation des interfaces - christouphe - 25-05-2010
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
J'ai essayé avec debug_print_backtrace() mais bon il faut récupérer la première valeur de la première case...un peu lourd.
EDIT: un équivalent de instanceof() en c++....heu non, en fait j'avais pas assez cherché :p :p merci !!!
correction:
Code PHP :
<?php
class A {
//...
public funtion toto($var1,$object) {
if ($object instanceof maClasse) {
echo '<br>'.$var1;
} else {
echo 'Pas le bon objet appelant';
}
}
class B {
//
public function appelleTotoDeA($oA) {
$oA -> toto("LOL",$this);
}
}
$oA = new A();
$oB = new B();
B -> appelleTotoDeA($oA);
C'est pour verrouiller certaines fonctions de mes fabriques.
RE: Dérive d'utilisation des interfaces - Shao - 29-05-2010
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.