Sans présager de mon questionnement sur l'autre fil de discussion "est-ce que ça vaut le coup ?"
Je trouve ton exemple très bien, même si je ne suis pas un expert en objet pour savoir s'il est plus commun/concis de faire :
Code : Tout sélectionner
$point = new point($_GET['id']); --> utilisation d'un constructeur
print_r($point);
ou plutôt de faire comme tu as fais
Note : avec les modèles actuels, en non objet on ferait ça comme ça :
Code : Tout sélectionner
$point = infos_point($_GET['id']);
print_r($point);
Je note au passage dans ton code que tu fais l'effort de très bien organiser les différentes propriétés, là où j'ai choisi par défaut la simplicité d'avoir :
champ dans la base = propriété du point
ce qui est certes plus court à coder genre, si je reprends ton code et fait à la cochon, ça donne ça :
Code : Tout sélectionner
$res = $res->fetch();
foreach ($res as $champ => $value )
$this->$champ=$value
Mais il faut alors une base avec des champs explicites, clairs, et homogènes (séparateur de mot, id de liaison, unicité à travers toutes les tables) ce qui n'est pas toujours le cas hélas aujourd'hui et cause donc de mal de tête à se demander comment c'est rangé ! et demanderait un bon ménage (C'est user_id ou id_createur ou id_user déjà ?)
bref, SQL, c'est pas bien prévu objet, mais on peut aider avec un peu de rigueur pour choisir les noms et ne pas avoir à tout le temps chercher comme s'écrit tel champs (ou tel propriété de l'objet point)
J'ignore si ta méthode est meilleure au global que ma technique plus sauvage