D'où vient la variable $moteur que tu dois fournir à ton objet ? Si il
existe un moyen quelconque pour l'internaute d'injecter autre chose qu'un
objet hadhoc dans ton moteur c'est ton script qui sera en panne !
Posted: Sat Jul 05, 2008 8:11 am Post subject: Re: Verification de la nature d'un objet
Quote:
...
Étant donné que php n'est pas typé, on peut passer n'importe quoi au
constructeur: un entier, un tableau ou un autre type d'objet...
Je viens de lire que l'on peut typer les classes.
Le constructeur de Voiture deviendrait alors
public function __construct( Moteur $moteur ) {
...
}
On mentionne dans la doc que le typage de paramètre ne fonctionne
qu'avec les variables de type object et array.
Le typage avec les types traditionnels, tels que int et string, n'est
pas supporté.
Posted: Mon Jul 07, 2008 11:10 pm Post subject: Re: Verification de la nature d'un objet
Luc a écrit :
Quote:
Bonjour,
J'aimerais savoir si c'est courant de vérifier la nature d'un objet en
php.
Supposons que j'ai une classe Voiture ayant un membre privé _moteur.
Lors de la création d'une voiture, on doit lui passer un objet Moteur
en paramètre.
Étant donné que php n'est pas typé, on peut passer n'importe quoi au
constructeur: un entier, un tableau ou un autre type d'objet...
Dans la classe voiture si je fais $this->_moteur->arreter() et que
_moteur est un entier, on devine la catastrophe.
Heu... Une erreur d'exécution, certes, mais de là à parler de
"catastrophe", c'est peut-être exagéré. A moins bien sûr que ton code ne
gère une fusée, une centrale nucléaire ou autre, mais là j'ai comme un
doute... Les erreurs de typage peuvent être "catastrophiques" dans un
langage sans vérification de type à l'exécution, surtout quand ce
langage permet d'accéder directement à la mémoire. Ce n'est pas le cas ici.
Quote:
Donc, dans le constructeur, je me dis que je devrais vérifier si je
reçois bien un moteur avec instanceOf.
Ce qui implique qu'un objet implémentant l'interface "Moteur" mais
n'étant pas instance d'une classe dérivée de Moteur ne sera pas accepté.
Par ailleurs, le fait qu'une classe hérite d'une autre (correction
structurelle) n'implique pas qu'elle implémente *correctement*
l'interface de la classe parent (correction sémantique). Par exemple,
une sous-classe de Moteur pourrait implémenter "arreter" de façon à
vider la base de données et envoyer un mail d'insulte à tes clients.
Quote:
Cependant, je trouve que ça alourdit le code et me dis que c'est au
"propriétaire" de la voiture de lui fournir un moteur valide.
C'est généralement la logique qu'on utilise dans un langage à typage
dynamique. Après, il ne faut pas confondre règle générale et
circonstances particulières, donc c'est à toi de décider de l'option
préférable en fonction du contexte. Ici, la question est surtout de
savoir qui instancie ta classe Voiture, et quelles sont les chances
qu'un paramètre incorrect soit passé. Si c'est dans ton code à toi que
personne d'autre n'y met le nez, il est peu probable que tu t'emmêles à
ce point les pinceaux. Si c'est une API destinée à être étendue par des
centaines de développeurs inconnus (genre Facebook par exemple), il eput
être bon d'être un peu plus restrictif.
Dans la classe voiture si je fais $this->_moteur->arreter() et que
_moteur est un entier, on devine la catastrophe.
Heu... Une erreur d'exécution, certes, mais de là à parler de
"catastrophe", c'est peut-être exagéré. A moins bien sûr que ton code ne
gère une fusée, une centrale nucléaire ou autre, mais là j'ai comme un
doute... Les erreurs de typage peuvent être "catastrophiques" dans un
langage sans vérification de type à l'exécution, surtout quand ce
langage permet d'accéder directement à la mémoire. Ce n'est pas le cas ici.
Tout est relatif :-)
Quote:
Donc, dans le constructeur, je me dis que je devrais vérifier si je
reçois bien un moteur avec instanceOf.
Ce qui implique qu'un objet implémentant l'interface "Moteur" mais
.... <skip
Si c'est une API destinée à être étendue par des
centaines de développeurs inconnus (genre Facebook par exemple), il eput
être bon d'être un peu plus restrictif.
Merci beaucoup de m'avoir fait part de vos commentaires, c'est très
apprécié.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum