8791 sujets

Développement web côté serveur, CMS

[resolu] POO : __get et __set methode "magique"....

Vous connaissez sans-doute :

public function __set($champ, $valeur) {
		$this->{$champ} = $valeur;
}
public function __get($champ) {
		return $this->{$champ};
}

Est-ce que cela est bien ou mal ?
Il me semble que l'on touche au "coté obscure" car mettre les membres de la classe en public reviendrais +ou- au même...
Utilisez vous ces méthodes "magiques" ?
Si oui dans quel cas pouvez vous les justifier ?
Modifié par Su4p (08 Jun 2011 - 18:04)
Ce n'est pas parce qu'on peut le faire qu'il faut le faire. Mais avoir la possibilité, c'est toujours un plus, même si là je n'ai pas d'exemple d'application en tête. C'est un peu comme le débat sur l'introduction du goto en PHP.

Ton exemple de code n'apporte rien en effet, et dans ce cas, autant travailler sur la visibilité des membres de classe.
Modifié par Planplan (08 Jun 2011 - 11:08)
@planplan : Ton exemple de code n'apporte rien en effet, et dans ce cas, autant travailler sur la visibilité des membres de classe.
Comment ça travailler sur la visibilité des membres de classe ???

@jb_gfx : parfait ! la réponse que je cherchais !! Désolé j'avais pas trouvé ce tutoriel. MERCI .
Su4p a écrit :
Comment ça travailler sur la visibilité des membres de classe ???
Je confirmais juste ce que tu disais pour ton exemple, à savoir utiliser les mots-clés de visibilité "public", "private" et "protected". Smiley cligne
Planplan a écrit :
Ce n'est pas parce qu'on peut le faire qu'il faut le faire.


Exactement comme dans l'exemple que j'ai posté et qui explique comment ça marche et dont la conclusion est de ne pas utiliser ces méthodes magiques. Smiley cligne
jb_gfx a écrit :


Exactement comme dans l'exemple que j'ai posté et qui explique comment ça marche et dont la conclusion est de ne pas utiliser ces méthodes magiques. Smiley cligne


La conclusion est un peu trop expéditive à mon goût. L'argument est essentiellement un argument de forme (compatibilité d'un outil de documentation spécifique, et d'un IDE) et non un argument de fond.

Il faut voir plus loin :
- l'outil de doc peut évoluer ou être changé
- l'IDE peut aussi évoluer ou être changé

La seule vrai question qui a du sens ici à se poser est : cela à t'il du sens et une plus-value en terme de POO ?

Pour ma part ma réponse est oui, c'est une très bonne pratique en terme d'encapsulation, pas la meilleure solution, mais une très bonne quand même.

Pouvoir surcharger les getters et setters permet d'encapsuler la visibilité des champs.
Sans cette possibilité de surcharge la seule solution est de ne pas utiliser les attributs de visibilité et de tout mettre en private avec des méthodes "just in case". C'est ce qui se fait dans beaucoup de langages comme par exemple en Java.

Cela permet de faire des API plus souples et plus légères sans sacrifier l'encapsulation et d'utiliser sans risque les attributs "public" ou "protected" sans être coincé par la suite en cas d'évolution.

Après IMHO la meilleure solution reste la déclaration d'accesseurs par propriété (et non un accesseur global) comme il est fait en actionscript et en c#. C'est beaucoup plus lisible et moins ambigüe.
Modifié par Ywg (13 Jun 2011 - 12:31)
Sujet clos
Aller à