Getter et Setter generateur ????

Par contre, se taper 30 getter et setter à la mimine pour 15 propriétés,
c'est ce que j'appelle du temps perdu

Maintenant une classe qui a autant de propriétés publiques révèle,
peut-être, un problème de conception non ?

Publiques ? Où est ce que tu as lu publique, toi ??????

Dans le fait que tu penses nécessaire de générer des getters/setters.
Entre un accès direct à un attribut - terme que je préfère à
"propriété", qui dans plusieurs langages a une sémantique quelque peu
différente, à savoir celle d'attribut calculé - et un accès via un
couple getter/setter qui fait exactement la même chose (retourner ou
modifier la valeur de l'attribut), je ne vois pas où est la différence
fondamentale. A vrai dire, les getters/setters à la mode Java/C++
n'existent qu'en raison de l'incapacité de ces langages à supporter des
vraies propriétés (ie: des attributs calculés).

La question était si l'un d'entre vous connaissait un outil pour aider à
générer les getter et setter comme cela se trouve depuis de nombreuses
années dans les outils de dev pour Java et C#.

Je suis désolé de la gène ou de l'incompréhension occasionnée par cette
simple question auprès des gens qui n'ont jamais été confrontés à l'écriture
d'objets ayant 15 propriétés en private nécessitant la mise en place de
getter et de setter.

Depuis le temps que je fais de l'OO avec divers langages, je n'ai jamais
été confronté à ce cas de figure...

Si tes 15 attributs nécessitent chacun une paire getter/setter, ils ne
sont pas si privés que ça. A ce jeu là, en ce qui me concerne, j'ai
comme une tendance à préférer utiliser par défaut des attributs publics.
Si le besoin se fait sentir de contrôler l'accès à certains de ces
attributs par la suite, il est facile de mettre cet accès en place au
cas par cas en utilisant les méthodes __get et __set - et en renommant
l'attribut (le vrai, celui utilisé pour l'implémentation), par exemple
en le préfixant d'un underscore. Je faisais déjà ça en Python il y a
plusieurs années, avant l'introduction d'un support plus évolué pour les
propriétés. Ce n'est peut-être pas en conformité avec la parodie d'OO
usuellement enseignée avec Java comme support (et donc restreinte à ce
que les concepteurs de Java ont compris de l'OO, c'est à dire pas grand
chose), mais ça marche à merveille.

@ ++

Stef

Entre un accès direct à un attribut [...] et un accès via un
couple getter/setter qui fait exactement la même chose (retourner ou
modifier la valeur de l'attribut), je ne vois pas où est la différence
fondamentale.

Je partage cette idée de l'inutilité des "getter/setter" en PHP.
Mais, dans le doute, j'aimerais bien être éclairé par ceux qui pensent
en avoir absolument besoin dans leurs classes.

On 21 mai, 03:28, Pascal PONCET <poncet.pas...@club-internet.fr>
wrote:

Je partage cette idée de l'inutilité des "getter/setter" en PHP.
Mais, dans le doute, j'aimerais bien être éclairé par ceux qui pensent
en avoir absolument besoin dans leurs classes.

Exemple (simple mais pas forcément concret) en PHP5 :

class Foo {
protected $x;
public function __construct() {
$this->x = new Bar();
}
public function setX(Bar $x) {
$this->x = $x;
}
public function getX() {
return $this->x;
}
public function exec() {
$this->x->exec();
}
}

Les accesseurs vs. un acces direct permettent de s'assurer qu'un
attribut est bien du type attendu (dans le cas de propriétés-objets).
Un accès direct avec une visibilité publique permettrait ceci :

$obj = new Foo();
$obj->x = NULL;

Que va-t-il alors se passer si on fait $obj->exec(); ? Une belle
erreur.

La solution consistant à introduire des vérifications de type de
l'attribut concerné dans chacune des méthodes représente un ajout de
code lourd et peu élégant (de mon point de vue).

Aussi, si un attribut, "public" à la base, passe "protected", ou
"private", il existe un risque élevé d'apparition d'erreurs dans les
scripts existants accédant directement aux attributs, alors que la
mise en place d'accesseurs offre une manière stable d'interroger/
affecter les attributs d'un objet, quelle que soit la visibilité
choisie pour un attribut.

PHP5 offre des méthodes "magiques" pour les accesseurs (__get() et
__set() par exemple), qui permettent de réduire significativement le
volume de code source (sourtout pour les "getters"), autant s'en
servir (sans en abuser).

Les accesseurs vs. un acces direct permettent de s'assurer qu'un
attribut est bien du type attendu (dans le cas de propriétés-objets).

Ok, merci, je n'avais pas envisagé cette utilisation.

La solution consistant à introduire des vérifications de type de
l'attribut concerné dans chacune des méthodes représente un ajout de
code lourd et peu élégant (de mon point de vue).

C'est effectivement le cas dans mes classes, mais pas pour toutes les
méthodes, seulement celles qui sont "sensibles".

Par ailleurs, dans les développements Web, j'utilise très rarement PHP
sans base de données. Dans ce cas, il est intéressant de créer des
classes d'objets "métier" correspondant aux tables de la base.
Dans ce type de classes, je trouve simple et efficace de concevoir
chaque champ de la table comme un attribut de l'objet. Ca peut faire pas
mal de propriétés qu'il serait lourd de gérer avec des accesseurs, non ?
Ca m'intéresserait de savoir comment d'autres gèrent cela.

PS: il faut dire que je code encore en PHP4, alors je ne suis pas très
concerné par la distinction public/private.

On 21 mai, 03:28, Pascal PONCET <poncet.pas...@club-internet.fr>
wrote:

Je partage cette idée de l'inutilité des "getter/setter" en PHP.
Mais, dans le doute, j'aimerais bien être éclairé par ceux qui pensent
en avoir absolument besoin dans leurs classes.

Exemple (simple mais pas forcément concret) en PHP5 :

class Foo {
protected $x;
public function __construct() {
$this->x = new Bar();
}
public function setX(Bar $x) {
$this->x = $x;
}
public function getX() {
return $this->x;
}
public function exec() {
$this->x->exec();
}
}

Les accesseurs vs. un acces direct permettent de s'assurer qu'un
attribut est bien du type attendu (dans le cas de propriétés-objets).

Non. Seulement qu'il est bien une instance d'une classe codée en dur. On
se fiche complètement que Foo->$x soit une instance de Bar, on veut
juste qu'il comprenne le message 'exec()'.

Un accès direct avec une visibilité publique permettrait ceci :

$obj = new Foo();
$obj->x = NULL;

Que va-t-il alors se passer si on fait $obj->exec(); ? Une belle
erreur.

Oui. Mais quelles sont les probabilités que cette erreur passe inaperçue
plus de quelques minutes ?

Depuis le temps que j'écris des programmes (pas forcément triviaux) avec
des langages à typage dynamique (Python) ou limite non typés (PHP4)
*sans* restriction d'accès ni getters/setters à tout bout de champ -
bref, avec des accès directs à des attributs publics - j'ai de bonne
raisons de ne plus acheter ce genre d'arguments...

Aussi, si un attribut, "public" à la base, passe "protected", ou
"private", il existe un risque élevé d'apparition d'erreurs dans les
scripts existants accédant directement aux attributs,

Evidémment, si tu change l'implémentation, il faut le faire proprement.
PHP4 n'a aucune solution pour ça, mais en PHP5, on peut renommer
l'attribut (par exemple en le préfixant d'un underscore) et utiliser les
méthode __get et __set pour maintenir l'interface (Python a un vrai
suuport pour les attributs calculés qui rend le refactoring en question
encore plus trivial). Accessoirement, restreindre l'accès ou non au
'vrai' attribut ne change pas grand chose au problème...

Bref, les getters/setters sytématiques ne sont qu'une verrue pour
contourner l'absence de support pour les attributs calculés.

sont pas si privés que ça. A ce jeu là, en ce qui me concerne, j'ai comme
une tendance à préférer utiliser par défaut des attributs publics.

Ah, mais là, je vais avoir du mal.

Bon, il y a peut etre une considération culturelle à prendre en compte....

Stef

slambert et d'autre part Bruno Desthuilliers et Thomas Labourdette, je
vais tenter une explication de texte. Vous me direz, les uns et les
autres, si j'ai bien compris de quoi vous parlez.

Merci.

Je rentre à l'instant de vacances, et je vais tenter de commenter ton post.

Publiques ? Où est ce que tu as lu publique, toi ??????
J'ai supposé que les « getter » et « setter » étaient des fonctions

publiques servant à accéder aux propriétés privées.

+1

Comme tu cherches à les générer automatiquement,

Je cherche surtout à ne pas avoir à le faire à la main totalement quand j'en
ai le besoin.

modification ni aucun contrôle, cela rend donc les propriétés publiques
ou tout comme.

ok, je ne l'avais pas vu comme cela dans l'écris précédent, mais il peut
etre effectivement possible de le présenter ainsi.

De deux choses l'une : soit tu laisses tes 30 fonctions inchangées et on
peut effectivement penser -- comme Thomas -- que ta classe a un problème
de conception ; soit tu les changes et alors ce n'est plus tellement
automatique -- comme semblait le supposer Bruno.

J'aime bien avoir mes accesseurs. Si j'ai besoin, je peux les completer
ulterieurement. Sinon, je dois retourner à mes appels et là c'est plus
embetants..

Est-ce que ma tentative d'explication enlève un petit peu de cette
incompréhension ?

Oui, et je t'en remercie.

Ceci dit, j'ai peut etre fait un peu trop de Java ces derniers temps....

@++

Stef

Exemple (simple mais pas forcément concret) en PHP5 :

..........

Merci.

Dans tes getter et setter, tu peux inclure des vérifications, et si besoin
est, ulterieurements, des trucs plus gorets comme des opérations
associées.... Oui je sais, mais la perfection n'est pas de ce monde, en tout
cas pas tout le temps : )

Mais comme le dit Bruno, il y a peut etre aussi un problème de culture.
Cette facon de faire est celle prescrite notamment en Java, et il y en a
d'autre.... Pour ma part, j'aurais tendance à rester dans ma méthode de
getter / setter, surtout si je peux les générer sans trop de contraintes ni
perte de temps......

Stef

Le Sun, 27 May 2007 21:54:00 +0000, slambert a écrit:

Je rentre à l'instant de vacances

Tu les passais où, à Toulouse ?

:-D

ok => [ ]

--
Christophe PEREZ
Écrivez moi sans _faute !

slambert <slambertPASDESPAM@vediovis.net> wrote:

Exemple (simple mais pas forcément concret) en PHP5 :

..........

Merci.

Dans tes getter et setter, tu peux inclure des vérifications, et si besoin
est, ulterieurements, des trucs plus gorets comme des opérations
associées.... Oui je sais, mais la perfection n'est pas de ce monde, en tout
cas pas tout le temps : )

Mais comme le dit Bruno, il y a peut etre aussi un problème de culture.
Cette facon de faire est celle prescrite notamment en Java, et il y en a
d'autre.... Pour ma part, j'aurais tendance à rester dans ma méthode de
getter / setter, surtout si je peux les générer sans trop de contraintes ni
perte de temps......

Quel est le coût en terme de charge serveur ?

Parce que bon, on commence à voir des scripts avec 10s de chargement par
page :)

FiLH

--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org