Tp 4 php classes models blogpoo
Thème :
Junior
1 vues ·6/9 leçons

04 - La Classe User et la Logique Métier

Ce document explique comment la classe User encapsule non seulement les données, mais aussi le comportement lié à la sécurité.


1. L’absurde : Disperser la logique de sécurité

Dans un code procédural classique (comme notre ancienne branche), la vérification d’un mot de passe ressemble à ça dans le fichier login.php :

// ❌ Le contrôleur fait le travail de l'utilisateur
$user = findUserByEmailOrUsername($email);
if (password_verify($password, $user['password'])) {
    // Connecté
}

Pourquoi c’est absurde ?

  • login.php (le contrôleur) est censé “diriger le trafic”, pas comprendre comment fonctionne la cryptographie de l’application.
  • Le mot de passe haché $user['password'] est exposé et manipulé en dehors de l’utilisateur.

2. La Solution Concrète : L’Encapsulation des comportements

Avec notre modèle User, c’est l’utilisateur qui vérifie lui-même son propre mot de passe.

// Dans User.php
public function verifyPassword(string $plainPassword): bool
{
    return password_verify($plainPassword, $this->password);
}

Dans le contrôleur (login.php), le code devient extrêmement lisible :

// ✅ Tell, don't ask !
$user = User::findByEmailOrUsername($email);

if (!$user->verifyPassword($password)) {
    return "Mauvais mot de passe !";
}

C’est ça la vraie POO ! On cache la complexité (password_verify) à l’intérieur de la classe. Si demain on passe à un autre système de hachage (ex: Argon2i), on ne modifiera que la classe User.php. Le contrôleur login.php n’aura même pas besoin de savoir que le système a changé !


3. L’absurde : Manipuler $_SESSION partout

Avant, pour connecter un utilisateur, on écrivait ça dans le contrôleur :

$_SESSION['auth'] = [
    'id' => $user['id'],
    'username' => $user['username'],
    // ...
];

Si demain on ajoute le champ avatar à l’utilisateur et qu’on veut le mettre en session, on doit chercher partout dans le code où $_SESSION['auth'] est défini (dans login.php, dans register.php, etc.).


4. La Solution Concrète : La méthode toSession()

On confie cette responsabilité à l’objet User. C’est lui qui sait quelles informations doivent aller dans la session.

// Dans User.php
public function toSession(): void
{
    $_SESSION['auth'] = [
        'id'       => $this->id,
        'username' => $this->username,
        'email'    => $this->email,
        'role'     => $this->role,
    ];
}

Usage dans login.php :

$user->toSession(); // Et c'est tout !

5. Résumé de la classe User

Grâce à cette classe, nous avons un objet central qui gère :

  1. Sa propre sauvegarde : $user->save()
  2. La gestion de son mot de passe : $user->hashPassword($mdp) et $user->verifyPassword($mdp)
  3. Sa mise en session : $user->toSession()
  4. La vérification de ses droits : $user->isAdmin()

La logique “métier” est parfaitement centralisée !

Prêt à passer à la suite ?

Vous avez terminé cette leçon sur 04 - La Classe `User` et la Logique Métier. Continuez votre apprentissage avec la prochaine leçon ou explorez d'autres formations.