Getter et Setter generateur ????

[slambert]

Salut !

Juste pour savoir, pour ceux qui font de l'objet : quand vous avez un objet
avec pleins de propriétés, et que vous voulez l'encapsuler proprement : vous
utilisez quoi pour générer automatiquement vos getter et setter ?

Eclipse le fait très bien pour Java, et VS pour C#.

Or, Eclipse pour php ne sais pas le faire, et Zend 5 non plus.

Grrrr : )

Merci du tuyau potentiel, car c'est un peu idiot de perdre du temps sur ce
genre de bêtises répétitives.

@++

Stef

[Francois Girault]

Post by slambert
Salut !
Juste pour savoir, pour ceux qui font de l'objet : quand vous avez un objet
avec pleins de propriétés, et que vous voulez l'encapsuler proprement : vous
utilisez quoi pour générer automatiquement vos getter et setter ?
Eclipse le fait très bien pour Java, et VS pour C#.
Or, Eclipse pour php ne sais pas le faire, et Zend 5 non plus.
Grrrr : )
Merci du tuyau potentiel, car c'est un peu idiot de perdre du temps sur ce
genre de bêtises répétitives.

Concernant eclipse, avec l'extension PDT ou phpeclipse, on peut écrire
des templates de code (cf les préférences de l'environnement)

Avec PDT, j'ai fait ce template :

public function get${name}() {
return $$this->${name};
}

public function set${name}($$${name}) {
$$this->${name} = $$${name};
}

je tape "getset" puis ctrl-espace, et hop.

C'est généralisable à toute structure répétitive et de base, PDT fournit
tout ce qu'il faut pour les boucles, les conditions, etc ...

[slambert]

Concernant eclipse, avec l'extension PDT ou phpeclipse, on peut écrire des
templates de code (cf les préférences de l'environnement)

Tu as une doc là dessus ?
PDT, c'est mieux que phpeclipse ?

Merci de ta réponse

@++

Stef

[Francois Girault]

Post by slambert
Tu as une doc là dessus ?

Non, désolé, mais dans les préférences, c'est limpide :

Window->Preferences

Puis section PHP -> Templates

Post by slambert
PDT, c'est mieux que phpeclipse ?

je trouve sa complétion plus sympa, plus php5-friendly que phpeclipse.

Comme PDT est un projet officiel rattaché à eclipse avec la
collaboration de Zend, m'est d'avis qu'il deviendra l'environnement de
référence sous eclipse.

Je vous recommande un paquet "PDT All-in-One", car il est assez pénible
à installer manuellement (beaucoup de dépendances).

Ceci dit, phpeclipse faut aussi un boulot respectable, s'il vous suffit,
pas besoin de plus ...

[slambert]

phpEclipse n'accepte pas cette manipulation, ou tout du moins pas la mnière
dont je l'ai tentée : )

Je vous recommande un paquet "PDT All-in-One", car il est assez pénible à
installer manuellement (beaucoup de dépendances).

Je vais aller tester, car je trouve phpEclipse parfois un chouilla limité.
Et puis cela ne fera pas de mal à ma culture.

Merci du tuyau !

@++

Stef

[slambert]

Post by slambert

Je vous recommande un paquet "PDT All-in-One", car il est assez pénible à
installer manuellement (beaucoup de dépendances).

Je vais aller tester, car je trouve phpEclipse parfois un chouilla limité.
Et puis cela ne fera pas de mal à ma culture.

Et bien pas de bol, fiasco total.

Le ctrl-espace ne marche pas, pas de completion automatique, pas de
descrition des fonctions quand tu passes le curseur dessus : j'au du rater
qque chose...

Dommage...

Stef

[Bruno Desthuilliers]

Post by slambert
Salut !
Juste pour savoir, pour ceux qui font de l'objet : quand vous avez un objet
avec pleins de propriétés, et que vous voulez l'encapsuler proprement : vous
utilisez quoi pour générer automatiquement vos getter et setter ?

Tu n'a pas l'impression qu'il y a une contradiction entre "encapsuler
proprement" et "générer automatiquement" ?

Accessoirement, encapsulation != restriction d'accès.

Post by slambert
Merci du tuyau potentiel, car c'est un peu idiot de perdre du temps sur ce
genre de bêtises répétitives.

php5 n'offre pas un mécanisme générique pour les accès aux attributs ?

http://www.php.net/manual/en/language.oop5.overloading.php

[slambert]

Post by Bruno Desthuilliers
Tu n'a pas l'impression qu'il y a une contradiction entre "encapsuler
proprement" et "générer automatiquement" ?

Non. Il suffit de regarder le résultat pour vérifier et de comprendre ce que
l'on fait.

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

Post by Bruno Desthuilliers
php5 n'offre pas un mécanisme générique pour les accès aux attributs ?
http://www.php.net/manual/en/language.oop5.overloading.php

Pour la surcharge ?

Mais pas de manière générique, ou alors je suis passé à travers, et ca me
rendrait bien service.

Stef

[Thomas Labourdette]

Post by slambert

Post by Bruno Desthuilliers
Tu n'a pas l'impression qu'il y a une contradiction entre "encapsuler
proprement" et "générer automatiquement" ?

Non. Il suffit de regarder le résultat pour vérifier et de comprendre ce
que l'on fait.
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 ?

@+

[slambert]

Post by Thomas Labourdette

Post by slambert
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 ??????

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.

@ ++

Stef

[Olivier Miakinen]

Puisqu'il semble y avoir une certaine incompréhension entre d'une part
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.

Post by slambert

Post by Thomas Labourdette

Post by slambert
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 ??????

J'ai supposé que les « getter » et « setter » étaient des fonctions
publiques servant à accéder aux propriétés privées. Comme tu cherches
à les générer automatiquement, et que je ne vois pas quel outil
automatique pourrait faire autre chose que les transmettre sans aucune
modification ni aucun contrôle, cela rend donc les propriétés publiques
ou tout comme.

Alors peut-être qu'une fois que les 30 fonctions auront été générées
automatiquement tu referas un tour manuel pour en supprimer une grande
partie et modifier la plupart de celles qui resteront, mais tu ne l'as
pas dit.

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.

Post by slambert
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.

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

[Thomas Labourdette]

Post by Olivier Miakinen
Puisqu'il semble y avoir une certaine incompréhension entre d'une part
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.

Post by slambert
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.

C'est exactement ce que j'en ai compris.

Post by Olivier Miakinen
Comme tu cherches
à les générer automatiquement, et que je ne vois pas quel outil
automatique pourrait faire autre chose que les transmettre sans aucune
modification ni aucun contrôle, cela rend donc les propriétés publiques
ou tout comme.

Pareil.

Merci pour ce résumé.

@+

[slambert]

Post by Olivier Miakinen
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.

Post by Olivier Miakinen

Post by slambert
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

Post by Olivier Miakinen
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.

Post by Olivier Miakinen
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.

Post by Olivier Miakinen
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..

Post by Olivier Miakinen
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

[Christophe PEREZ]

Post by slambert
Je rentre à l'instant de vacances

Tu les passais où, à Toulouse ?

:-D

ok => [ ]

[slambert]

Post by Christophe PEREZ

Post by slambert
Je rentre à l'instant de vacances

Tu les passais où,

à Tenerife : )

Post by Christophe PEREZ
à Toulouse ?

Non, à Nantes, andouille !
: )

Post by Christophe PEREZ
Christophe PEREZ

yeah, je l'ai !

Salut Christophe, bonjour à la Martinique : )

Stef

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by slambert

Post by Christophe PEREZ
à Toulouse ?

Non, à Nantes, andouille !

Alors, c'est à Vire.

[Bruno Desthuilliers]

Post by docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by slambert

Post by Christophe PEREZ
à Toulouse ?

Non, à Nantes, andouille !

Alors, c'est à Vire.

Ou à Guéméné...

[slambert]

Post by Bruno Desthuilliers

Post by docanski

Post by slambert

Post by Christophe PEREZ
à Toulouse ?

Non, à Nantes, andouille !

Alors, c'est à Vire.

Ou à Guéméné...

Cherchez pas les gars, ca parle de foot et de la fin de saison des
Girondins.

Stef

[Bruno Desthuilliers]

Post by slambert

Post by Thomas Labourdette

Post by slambert
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).

Post by slambert
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.

Post by slambert
@ ++
Stef

[Pascal PONCET]

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.

[Gromitt]

Post by Pascal PONCET
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).

[Pascal PONCET]

Post by Gromitt
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.

Post by Gromitt
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.

[slambert]

Post by Pascal PONCET
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.

Et bien comment te dire, tout dépend du projet. Le truc sur lequel je suis
actuellement est tellement obscur, tellement victime de son passé et de son
ancienneté que décision a été prise de sortir la cavalerie et la machine a
bazooka. Dès que je le peux, je crée un objet correspondant à ma table, et
je fais mes propriétés correspondant aux champs de la table. J'ai mes
accesseurs, mes methode load update delete et d'autres trucs plus
contextuels. Cela me permet petit a petit d'enlever mon sql de mes pages
html, et d'éviter les répétition de requêtes sql qui bizarrement ne sont pas
tout le temps faites de la meme manière pour le meme résultat (problème des
projets à histoire lourde ayant eu plusieurs intervenants au fur et à mesure
du temps, ceux ci n'ayant pas toujours pu se parler.)

Alors oui, c'est lourd, mais au fur et à mesure, ça nettoie et ça simplifie.
Et je sais que pour écrire un Article, par exemple, la requête est à un seul
endroit. Bien sur, je pourrais aller encore plus loin et faire un mapping
relationnel /objet, mais là j'ai pas le temps, ni meme de faire une couche
DataService supplémentaire. Parceque non seulement faut nettoyer, mais faut
avancer et évidemment il fallait rendre le tout pour hier.

Pour ce qui est des accesseurs, il y a des IDE ou tu sélectionnes tes
propriétés et tu génères tes acceseurs. Après, tu peux repasser dessus si
nécessaire, mais le gros du travail est fait. Et je ne suis pas sur que cela
prenne beaucoup plus de temps système par la suite de les utiliser. Par
contre, le jour où tu dois vérifier quelque chose dedans, tu es bien content
de les avoir...

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

Et bien je pense que vu la tournure des évènements, les gros projets vont
aller dans cette direction. A la fois pour segmenter les développement, et
ensuite parceque on se traîne vraiment une réputation de boulets et
d'amateur en tant que dev PHP. La prog Objet et le MVC par exemple sont
devenus des critères de sélection et de recrutement ne serais ce que pour
faire le tri et pour pallier cette image désastreuse.

Pour ma part, j'aimerais meme que PHP devienne un jour une plate-forme qui
fasse serveur d'application. Je m'explique :
Il peut parfois être nécessaire et bienvenue de mettre toutes tes chaînes de
caractère dans un fichier texte, XML, voir dans une classe avec des
statiques. Les pages font ensuite appel à ces constantes, mais les écritures
réelles sont en dehors du code et du html. Jusque là, rien de vraiment très
révolutionnaire, ça existe depuis un certain temps maintenant. Or,
aujourd'hui, cette solution signifie que à chaque demandes de pages, tout
cela se retrouve en mémoire le temps de l'appel, avec un ou plusieurs accès
disque. A chaque fois, pour chaque visiteur, chaque appel de lien. Or, un
serveur d'application charge ces élément en mémoire une seule fois. Ils sont
donc tout le temps accessible, et le fichier est lu une seule fois. Et là,
dans ce genre d'architecture, ça commence à compter.

@ ++

Stef

[Bruno Desthuilliers]

Post by Gromitt

Post by Pascal PONCET
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.

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()'.

Post by Gromitt
$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...

Post by Gromitt
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.

[slambert]

..........

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

[FiLH]

Post by slambert
..........
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

[slambert]

Post by FiLH

Post by slambert
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 ?

Beaucoup moins que des requêtes sql non optimisées à répétition, ou qu'un
projet qui devient totalement inmaintenable suite au bout de 6 ans de maj et
d'upgrade technologiques avec ajouts de nouvelle fonctionnalités à la
va-vite.

Accessoirement, il vaut mieux parfois se permettre quelques petit include ou
une vraie structuration de développement avec découpage en couches, surtout
sur de gros projets qui entraîne l'intervention de multiples acteurs sur
plusieurs années, acteurs de niveaux hétérogènes encadrés par des chefs de
projet ayant parfois une vision purement comptable entraînant un
développement en mode "WriteOnly / NoComment". La lisibilité pure et les
tentatives de prévision des conneries futures prennent alors le pas sur
l'optimisation forcenée que nous devrions pourtant tous avoir en tête de
mettre en oeuvre. Il vaut mieux parfois acheter une barrette de Ram ou un
processeur que de devoir pleurer au bout de la quatrième année.

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

On en a toujours vu, il suffit de se rappeler l'affalement et le crash de la
plate-forme d'hébergement de Online.fr en 2001.

Stef

[FiLH]

Post by FiLH

Post by slambert
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 ?

Beaucoup moins que...

Hum.. au delà de l'argument d'on peut toujours trouver pire ? ? :) :)

Je veux dire qu'entre des attributs publics bien gérés dans une bonne
prog et faire des getter/setter systématiquement...

Est-ce qu'à force d'ajouter de petites choses comme ça.

FiLH

[slambert]

Post by FiLH

Beaucoup moins que...

Hum.. au delà de l'argument d'on peut toujours trouver pire ? ? :) :)

De la lisibilité et de la prévision de bétises sur des gros machins
imbuvables qui enflent avec le temps ?

Tiens rigole pas, j'ai eu un soucis avec des dates à afficher. Il fallait le
faire a un format différend selon les objets. Hop, un coup dans les Getter,
et c'etait bon. Sinon, fallait se taper tous les appels.

Or, parfois, tu es dans des environnements im-pré-vi-si-bles. La demande
peut changer du jour au lendemain, et il faut etre près à tout. Mettre des
accesseurs fais parti des solutions préventives que j'ai trouvé pour pallier
aux crises de délire que je crois régulièrement.

Bon, encore une fois, je comprends que dans l'absolue, systématiser cette
tactique n'est pas tout le temps très opportun. Mais bon, là, je fais ce que
je peux avec ce que j'ai.

Et puis ma question au depart était juste de savoir si je pouvias
automatiser le truc pour ne pas tout écrire à la main car plus que du temps
système, ca coute du temps de dev : )

Post by FiLH
Est-ce qu'à force d'ajouter de petites choses comme ça.

Ah si. Bien sur que si.

A force d'ajouter des conneries aussi, tu diras. Mais bon, c'est encore un
autre problème : ))))

Stef

[bruno desthuilliers]

Post by slambert
..........
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....

Ce n'est pas forcément goret - après tout, le propre d'un attribut
calculé, c'est qu'il y ait des calculs, non ?-)

Post by slambert
Mais comme le dit Bruno, il y a peut etre aussi un problème de culture.

Probablement, en effet. J'avoue que la pratique assidue de langages
intelligement conçus (comme Python ou Ruby) n'est pas sans avoir des
effets secondaires, notamment sur le seuil de tolérance au code
inutile !-)

Post by slambert
Cette facon de faire est celle prescrite notamment en Java,

Pour la bonne raison que Java est trop débile (désolé d'appeler un
félidé domestique un chat) pour supporter quelque chose d'aussi
évident que les attributs calculés. Accessoirement, prendre exemple
sur Java est le meilleurs moyen de finir avec une usine à gaz AMHA, et
une des dernières choses à faire en PHP. Pour l'anecdote, j'ai
récemment eu à porter un plugin DotClear sous Spip (du php dans les
deux cas). Il s'est avérer que la partie "utile" des 900 et quelques
ligne de la classe supposée être au coeur de l'affaire tenait en *1*
(une) ligne - en l'occurence une expression rationnelle. Et en plus,
cette expression était légèrement incorrecte. No comment...

Post by slambert
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......

Pour ma part, j'ai tendance à considérer que le meilleurs code est
celui qu'on n'écrit pas - parce qu'on n'a pas à le maintenir.

Maintenant, je ne doutes pas que tu ait tes raisons de choisir cette
approche. Simplement, mon expérience est qu'en PHP, plus on fait
simple et mieux on se porte.

Post by slambert
Stef

[slambert]

Post by bruno desthuilliers

Post by slambert
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....

Ce n'est pas forcément goret - après tout, le propre d'un attribut
calculé, c'est qu'il y ait des calculs, non ?-)

oui mais non, y a aussi le fait que parfois, mettre a jour une propriété
entraine des choses à faire. Ben oui, ca arrive......

Post by bruno desthuilliers

Post by slambert
Cette facon de faire est celle prescrite notamment en Java,

Pour la bonne raison que Java est trop débile

Tout n'est pas à jeter en Java. Surtout le bébé avec l'eau du bain...

Post by bruno desthuilliers
Maintenant, je ne doutes pas que tu ait tes raisons de choisir cette
approche. Simplement, mon expérience est qu'en PHP, plus on fait
simple et mieux on se porte.

Oui, sauf quand on est dans un usine à gaz mal faite. Autant la transformer
en usine a gaz plus standard : )

Stef

[slambert]

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

[g***@gmail.com]

Post by slambert
Salut !
Juste pour savoir, pour ceux qui font de l'objet : quand vous avez un objet
avec pleins de propriétés, et que vous voulez l'encapsuler proprement : vous
utilisez quoi pour générer automatiquement vos getter et setter ?
Eclipse le fait très bien pour Java, et VS pour C#.
Or, Eclipse pour php ne sais pas le faire, et Zend 5 non plus.
Grrrr : )
Merci du tuyau potentiel, car c'est un peu idiot de perdre du temps sur ce
genre de bêtises répétitives.
@++
Stef

J'ai ecrit un post sur la facon de 'simuler' les accesseurs en PHP en
utilsant la methode __call de PHP5.
Tu peux le trouver a cette addresse:

http://www.vmeste.fr/index.php?2007/05/31/131-simuler-des-accesseurs-en-php

[slambert]

Post by g***@gmail.com
J'ai ecrit un post sur la facon de 'simuler' les accesseurs en PHP en
utilsant la methode __call de PHP5.
http://www.vmeste.fr/index.php?2007/05/31/131-simuler-des-accesseurs-en-php

C'est très joli.

Si seulement j'avais eu cela au début de mon developpement, j'aurais pus
l'intégrer depuis le début....

Merci beaucoup de cet article !

Stef

[FiLH]

Post by slambert

Post by g***@gmail.com
J'ai ecrit un post sur la facon de 'simuler' les accesseurs en PHP en
utilsant la methode __call de PHP5.
http://www.vmeste.fr/index.php?2007/05/31/131-simuler-des-accesseurs-en-php

C'est très joli.

Bonjour la lourdeur de l'appel.

Post by slambert
Si seulement j'avais eu cela au début de mon developpement, j'aurais pus
l'intégrer depuis le début....

En même temps mettre des setters et des getters sur tous les attributs
« privés » :)

FiLH

[slambert]

Post by FiLH

Post by slambert
C'est très joli.

Bonjour la lourdeur de l'appel.

Oui mais y a rien de mieux. Et visiblement aucun IDE n'a pensé à le faire
pour PHP, alors que Eclipse le propose pour Java et VS pour C#.

Post by FiLH
En même temps mettre des setters et des getters sur tous les attributs
« privés » :)

C'est le concept. Ca peut se discuter, mais une fois ce type de méthodologie
de développement choisi, c'est comme cela que ca se passe....

Stef

[FiLH]

Post by slambert

Post by FiLH
En même temps mettre des setters et des getters sur tous les attributs
« privés » :)

C'est le concept. Ca peut se discuter, mais une fois ce type de méthodologie
de développement choisi, c'est comme cela que ca se passe....

Ce qui n'est pas une preuve de validité :) Si les développeurs savaient
programmer ça se saurait depuis longtemps...

Un objet se manipule avec un certain nombre de propritétés qui peuvent
être implémentées avec des attributs qui n'ont pas à être vus.

Un exemple : si j'ai un objet qui stocke un chemin de fichier, je peux
pour des raisons d'optimisations faire un resolvepath sur le fichier
(pour résoudre les liens symboliques).
Je n'ai AUCUNE raison d'exposer par un setter ou un getter le chemin
final.

FiLH

[gat]

Post by FiLH
En même temps mettre des setters et des getters sur tous les attributs
« privés » :)

Si tu lis mon article, tu remarques que la classe 'utils' (possèdant
la méthode '__call') est abstraite et que la classe 'user' (possèdant
les attributs) en hérite.
Par conséquent, les getteurs et setteurs ne sont "mis" que sur les
attributs public et protected, pas sur les privés ;)

Gaetan Mathey
http://www.vmeste.fr

[FiLH]

Post by gat

Post by FiLH
En même temps mettre des setters et des getters sur tous les attributs
« privés » :)

Si tu lis mon article, tu remarques que la classe 'utils' (possèdant
la méthode '__call') est abstraite et que la classe 'user' (possèdant
les attributs) en hérite.
Par conséquent, les getteurs et setteurs ne sont "mis" que sur les
attributs public et protected, pas sur les privés ;)

J'avais quand même lu en diagonale..

FiLH