Getter et Setter generateur ????

Je rentre à l'instant de vacances
Tu les passais où,

à Tenerife : )

à Toulouse ?

Non, à Nantes, andouille !
: )

Christophe PEREZ

yeah, je l'ai !

Salut Christophe, bonjour à la Martinique : )

Stef

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.

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

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...

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

slambert <slambertPASDESPAM@vediovis.net> wrote:

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


--
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

On 27 mai, 23:54, slambert <slambertPASDES...@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....

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 ?-)

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 !-)

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...

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.

Stef

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......

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...

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

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 : )

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

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

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
slambert nous narre ce qui suit en ce 28/05/2007 16:31 :

à Toulouse ?

Non, à Nantes, andouille !

Alors, c'est à Vire.
--
docanski

- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr

On May 17, 3:08 pm, slambert <slambertPASDES...@vediovis.net> wrote:

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