Il te manque pas mal de classes différentes pour avoir une architecture objet qui va t'aider à assimiler les concepts de la POO. Les objets sont de petits éléments, il ne font généralement qu'un seul truc.
Ta classe utilisateur devrait simplement être capable d'aller chercher les infos d'un user dans la DB à partir d'un id, enregistrer un nouvel utilisateur, et éventuellement avoir des méthodes de recherche sur plusieurs utilisateurs (perso je sépare la logique 1 user : classe instanciable/ multi users: module de fonctions).
Donc, ta classe user ne serait qu'une couche d'accès à la base de données des utilisateurs. En ce sens, il n'est pas logique qu'elle ait une variable mdpConfirm. Elle devrait par contre accepter mdpConfirm dans sa méthode qui compare des données entrées par l'utilisateur avec des données en base pour confirmer son authentification lors du login, en renvoyant true ou false ; ou bien ce sera directement dans le constructeur, qui testera l'authentification, et il faudra donc ensuite demander à la classe si elle est authentifiée
$u = new user(...);
if($u->is_auth()) { ...
Dans la même logique, je sortirais la gestion de la session de ta classe, notamment le session_start() qui n'a rien à faire là.
Comme je te disais, il te manque pas mal de classes, ici par exemple je ferais une classe qui va gérer la session d'un utilisateur, comme un objet instancié qui reste persistant entre les appels de page. Mais tu peux également regrouper ceci dans ta classe utilisateur. dans ce cas, elle aura beaucoup de méthodes d'accès à des données de session.
Mais perso je séparerais la classe utilisateur d'accès aux données de la DB avec ma classe qui gère les données persistantes, car la première prends dans son constructeur des données de l'utilisateur, la seconde ne prends pas de variables dans son constructeur et sert uniquement d'interface aux données de la session.
voilà quelques réflexions qui pourront peut-être t'aider, mon idée était surtout de dire que les objets doivent se concentrer sur des points logiques très précis, et que pour cette raison il ne faut pas hésiter à créer une myriade de classes différentes.
Ta classe utilisateur devrait simplement être capable d'aller chercher les infos d'un user dans la DB à partir d'un id, enregistrer un nouvel utilisateur, et éventuellement avoir des méthodes de recherche sur plusieurs utilisateurs (perso je sépare la logique 1 user : classe instanciable/ multi users: module de fonctions).
Donc, ta classe user ne serait qu'une couche d'accès à la base de données des utilisateurs. En ce sens, il n'est pas logique qu'elle ait une variable mdpConfirm. Elle devrait par contre accepter mdpConfirm dans sa méthode qui compare des données entrées par l'utilisateur avec des données en base pour confirmer son authentification lors du login, en renvoyant true ou false ; ou bien ce sera directement dans le constructeur, qui testera l'authentification, et il faudra donc ensuite demander à la classe si elle est authentifiée
$u = new user(...);
if($u->is_auth()) { ...
Dans la même logique, je sortirais la gestion de la session de ta classe, notamment le session_start() qui n'a rien à faire là.
Comme je te disais, il te manque pas mal de classes, ici par exemple je ferais une classe qui va gérer la session d'un utilisateur, comme un objet instancié qui reste persistant entre les appels de page. Mais tu peux également regrouper ceci dans ta classe utilisateur. dans ce cas, elle aura beaucoup de méthodes d'accès à des données de session.
Mais perso je séparerais la classe utilisateur d'accès aux données de la DB avec ma classe qui gère les données persistantes, car la première prends dans son constructeur des données de l'utilisateur, la seconde ne prends pas de variables dans son constructeur et sert uniquement d'interface aux données de la session.
voilà quelques réflexions qui pourront peut-être t'aider, mon idée était surtout de dire que les objets doivent se concentrer sur des points logiques très précis, et que pour cette raison il ne faut pas hésiter à créer une myriade de classes différentes.