Hello !
 
Je suis en train de "convertir" tout un extranet basé sur une gestion (avec calculs de chiffres d'affaire, marges, ... selon pleins de pièces correspondant à tes tables de la BD) en PHP5 pour utiliser les classes/objets.
 
Mon idée actuelle est que, dans mes constructeurs, il y aura une requête qui ira initialiser tous mes attributs privés. Genre :
 

 
Est-ce trop couillon de faire comme ça, ou ça passe ?
Merci à vous d'émettre des critiques qui pourront me faire avancer

avec un "function" entre public et __contruct évidemment...

Et le but est?

Le but est de construire un objet ayant tous les chiffres (les montant HT, le taux de TVA...), et d'utiliser les valeurs pour faire tous mes calculs via les méthodes publiques... entre autres.
 
...je suis assez clair ?...

pas des masses    
 
juste, une piste apres tu en fais ce que tu veux :
as tu regardé du coté des ORM ?
Tu as par exemple http://propel.phpdb.org/trac/ mais biensur il en existe d'autre.
Cela te permettra de ne pas recoder à la main la couche d'acces aux données persistantes.
 
 

Etant donné que je débute en POO sur PHP, j'ai du mal à cerner ce que Propel apporte...
 
J'essaie d'être un peu plus clair :
ma BD n'est là que pour être consultée, pas de modif.
 
Ce que je veux faire, c'est créer un objet selon son nom reseigné. Le reste est récupérer de la BD via une requête.
Ca, je veux le faire dans mon constructeur.
 
(Après, toutes les méthodes publiques calculent tout le reste... c'est pour ça que je pass à la POO... mais on s'en fiche pour l'instant.)
 
Ma question :
Est-ce correct de construire un objet grâce au résultat d'une requête (que je souhaite effectuée dans le constructeur) ? Est-ce moche ?

Perso je trouve assez bien ..  Apres tu pourras appeller toutes tes methodes comme $monObjet->maMethode() et ça aura rellement un sens ... Donc moi je vote pour... Surtout que l'aternative serait de faire en sorte que ton objet soit constuit par une autre methode que tu appelle apres le constructeur .. et ca c'est crade je trouve (dans ce cas de figure)

Pour : 1
Contre : 0
 
Donc, je pars là-dessus. Merci de ton avis esox_ch !

En même temps je te conseille d'attendre d'autres avis avant de te lancer la dedans ... Je suis loins d'etre infaillible

Personellement, je suis du même avis que esox_ch tant qu'on ne récupére que les informations susceptible d'être utiles dans les traitements habituels.
 
En bref, récupérer dans la base les caractéristiques de l'objet est (dans le cas présent mais aussi de maniére générale) une chôse à faire dans le constructeur mais il n'est pas forcément utile de récupérer à la fois l'ensemble des coordonées spaciales de chaque point remarquable de l'objet (utile pour le représenter en 3D) et les infos lié au calcul du coup de revient ou du prix de vente unitaire de l'objet. (calcul de coup)
 
A toi donc de sélectionner les bonnes informations quitte à prévoir une méthode interne à l'objet permettant de récupérer le reste quand on a besoin d'une information qui ne serait utilisé normalement qu'une fois tous les X jours.
 
PS : En fait, en me relisant, j'ai l'impression que ma réponse est en partie en dehors de la question. Ce qu'est à retenir, c'est que je suis du même avis que esox_ch.

est-ce qu'il y aura potentiellement d'autres requetes dans ta classe? Si oui, vas-y. Si non, j'emets une reserve. C'est dommage de faire une classe qui a absolument besoin d'une base pour fonctionner alors qu'il suffit de l'initialisation par appel de methode

lol, je te remercie omega2. Je retiens ta réponse.
 
Pour : 2
Contre : 0
 
Et venant de omega2, c'est adopté.
 
Merci à tous !!

josserand_ joss > je suis pas plus infaible que esox_ch. Ca m'est déjà arriver de sortir de grosse bétises et que ca soit esox_ch, gatsu ou d'autres et parfois même des tout nouveaux qui me corrigent.

Sûr ! Comme tout le monde ! Mais t'avoueras que je te vois souvent apporter des éléments de soluce... voir les soluces.

Y a des jours où c'est le cas, et des jours où j'envois balader beaucoup de monde.
Mais une chôse que je n'aime pas faire il est vrai, c'est envoyé des débutant sur une fausse piste.

cinocks > Je vois pas ce que tu veux dire ... Si sa classe construit un objet qui tire ses caracteristiques de la base de donnée, je vois pas en quoi le fait d'avoir une ou plusieurs requete va changer quoique ce soit..
Tu fais ce que tu as besoin, quand tu en a besoin et basta ..
 
@omega : Moi non plus, a part quand un gugus nous arrive sur OSA en nous expliquant que le drapeau de windows se fige au moment du boot ... La je lui demande de recopier a la main toutes les données du bios et de nous les poster

Perso moi j'ai pas compris un truc.

Donc en gros si tu as requête A et une requête B, tu auras un objet A dont les propriètés sont en gros ce que te retourne la requete A, et pareil avec l'objet B et la requete B?
 
Mais par contre tes objets A et B ont des méthodes communes ( par exemple calcul de cout). Ces methodes, j'imagine qu'elles auront des implémentations différentes ( vu que les objets A et B n'ont pas les mêmes propriétès).
 
Bref je trouve que ça sent un peu le binz... tout ça biensur a condition que tu aies bien des objets A et des objets B.

anapajari > Bein s'il a 2 types d'objets, il se fait 2 classes qui implementent la meme interface qui defini les methodes qu'on en commun tous les objets ... Je vois pas trop ton probleme ?

pas de problème, c'est bien à ça que servent des interfaces!
 
C'est juste que j'imagine le système avec 50 requetes <=> 50 objets ... J'ai du mal a croire qu'il s'en sorte avec une seule interface.
 
edit doigt qui rippe: Donc si c'est pour apprendre la POO pourquoi pas ( encore que je commencerais pas en php) mais si c'est pour faire vite pas sur que ça soit le top

anapajari > Ca dépend de ce qu'ils ont besoin de faire et de comment il prévois le systéme. Tu peux avoir par exemple avoir à vendre 20 modéles de cartes méres pour PC, 5 boitiés, 10 écrans ... et une seule interface pour les classes correspondant à tout ça.
Par contre, c'est sur que s'il a des camion en location avec des employés en intérim, du matériel en vente et que sais je encore, là, ca se corserait pour faire rentrer tout ça dans une seule case.

Certes, oui, il y aura surement de l'optimisation à faire derrière... mais pour le moment, je "convertie" toutes mes pages en POO.

Suis désolé ( et c'est sans méchanceté josserand_joss), mais c'est pas pour me rassurer sur le coté bien pensé POO du truc.
L'optimisation des classes, par l'utilisation d'interfaces, vaut mieux le faire au début sinon c'est sans intéret!!!
 
 

 
Je trouve dommage, si la classe fonctionne sans avoir besoin d'acceder à une base, de rajouter un acces base en phase d'initialisation s'il est possible de passer les valeurs en parametre du constructeur.
 
Dans un cas, la classe est autonome et peut etre reutiliser pour d'autres projets n'ayant pas besoin de base. Dans l'autre elle depend d'une base.

Etant donné que je répète souvent les mêmes calculs, que ceux-ci peuvent difficilement faire office de fonctions (si ce n'est avec 15000 paramètres)..., le but de tout ça est de me faciliter la tache quand on me demande de calculer sur une page quelque chose qui a déjà été à moitié calculé sur une autre page...
En gros, au lieux d'avoir des pages de 800 lignes alors que je pourrais en avoir que 400 grâce à la POO, j'opte !
 
Je répète, on optimisera en fonction... mais chaque chose en son temps.
 
Pour le moment, j'ai tout les éléments qu'il me faut pour avancer... Et je vous en remercie.

 
Oui mais ça signifie s'amuser a prendre tout les params avant l'appel du constructeur .. ce qui est en general super long et chiant a ecrire . Dans son cas je doute qu'on puisse faire beaucoup mieux ...  
A la limite une methode getDonnee() qui choppe la base de donnée , et qui est appellée dans le constructeur ... mais moi je le ferais pas...

ma reponse est par rapport au sujet. Il n'est pas dit que c'est aussi complexe au debut

De toutes façon, il y a pas de secret, si tu as 50 objets totalements distincts entre eux (dans le sens ou toutes les methodes sont differentes), c'est quand meme une archi pas mal grosse, et donc faut pas s'etonner si tu te retrouve avec pas mal de classes

Oui on est bien d'accord.
Par contre avoir 50 requetes dans une appli, c'est tout de même fréquent! Or (si j'ai bien tout compris), à chaque requête correspondra un objet.
 
Imaginons 2 requetes, l'un qui regardes le prix des legumes ( dans la table légume), l'autre le prix des fleurs ( dans la table fleur). J'ai donc 2 objets Legume et Fleur, mais en fait ces 2 objets font exactement la même chose!!! Juste avec des données provenant de tables différentes.
 
N'aurait-il pas été plus judicieux de créer une seule classe Produit, ou au pire une classe mère Produit dont héritaient Fleur et Legume?
 
C'est juste pour ça que je trouve ça l'idée une requete <=> un objet, s'pas forcément top...

Oui, c'est sûr que je vais me retrouver avec pas mal de Classes, ou au moins beaucoup de méthodes dans chaque classe... mais ça sera toujours mieux que ce qui existe actuellement en PHP4.
 
Je m'y jette, et ça sera forcément mieux... en tout cas pour la suite.

 
Quand je dis qu'il doit faire 1 classe par truc, je dis pas qu'elle doivent etre toutes independantes , c'est clair que l'heritage c'est pas pour les chiens

Au fait, qui a dit qu'aucun objet ne pourait utiliser la même classe qu'un autre?
Entre l'héritage et les interfaces plus la possibilité d'avoir plusieurs objets correspondant à la même classe, il a quand même de quoi faire.

et

Mais j'ai jamais dit qu'il n'y avait pas moyen de faire proprement ce dont josserand_joss parle!!!
 
Ce qui m'inquiète c'est juste:

ça donne l'impression qu'il prend les pages une par une, prends chaque requete, en fait un objet, sans vraiment réfléchir à comment optimiser le bouzin.
 

Et ça c'est pas une bonnée idée, un truc mal pensé objet dès le début c'est super dur à optimiser une fois terminé!

C'est vrai que vu comme ça ... Et c'est vrai aussi qu'a part tout refaire à nouveau depuis zéro, c'est super compliqué de modifier une architecture d'objets afin de les optimiser ou rendre chaque objet et l'ensemble des objets plus logiques.

No problem, je me suis mal exprimer, bien sûr que je fais attention à tout ça ! Je n'y vais à la barbare. Don't worry :-)