Délimiter les responsabilités des classes

Quand les règles d’un contact et les requêtes SQL se retrouvent dans la même classe, une modification du stockage risque d’obliger à réécrire la validation métier. À l’inverse, un objet qui gère uniquement ses données ne devrait pas connaître PDO. Vous allez répartir ces responsabilités avant d’ajouter les opérations de lecture et d’écriture.

Deux responsabilités distinctes

La classe Carnet\Modele\Contact représente un contact et protège ses données. Elle porte les règles qui concernent directement cet objet : son nom doit être valide, son identifiant peut être absent avant l’enregistrement et les champs facultatifs vides sont normalisés. Ces règles ont déjà été mises en place dans les leçons précédentes ; vous les conservez dans le modèle plutôt que de les recopier ailleurs.

La classe Carnet\Depot\ContactDepot aura une autre mission : faire le lien entre l’application et le stockage des contacts. Elle recevra les demandes d’accès aux données, comme lister, enregistrer ou supprimer un contact, puis les traduira en opérations sur la base. Elle ne décide pas si un nom est acceptable : cette règle appartient à Contact.

Passer la dépendance au dépôt

Pour exécuter plus tard des opérations MySQL, le dépôt aura besoin d’un objet PDO. Au lieu de créer lui-même cette connexion, il la reçoit dans son constructeur. Cette manière de fournir à une classe ce dont elle dépend est une injection de dépendance ; ici, la dépendance est passée en paramètre au moment de construire le dépôt.

<?php

declare(strict_types=1);

namespace Carnet\Depot;

use PDO;

final class ContactDepot
{
    public function __construct(
        private PDO $connexion
    ) {
    }
}

La propriété privée $connexion est initialisée par le constructeur et typée PDO. La promotion de propriété dans la signature du constructeur évite de répéter sa déclaration et son affectation. Cette classe est volontairement limitée à sa dépendance pour cette étape : les méthodes de requête seront ajoutées dans les leçons consacrées à PDO.

Ce que cette séparation vous apporte

Le modèle reste utilisable sans base de données : vous pouvez créer un objet Contact et vérifier ses règles sans ouvrir de connexion. Le dépôt, lui, concentre les accès au stockage. Plus tard, le contrôleur demandera au dépôt les données nécessaires, puis transmettra les valeurs à afficher ; il ne devra pas contenir les requêtes SQL ni les règles de validation du contact.

Le constructeur rend aussi la dépendance visible : pour construire un dépôt, l’application devra lui fournir un objet PDO. Le dépôt ne choisit donc ni le serveur ni les paramètres de connexion. Vous découvrirez la configuration de cet objet dans la leçon suivante, puis vous utiliserez le dépôt pour accéder aux contacts.

À retenir

• Contact porte les données et les règles propres à un contact.
• ContactDepot regroupe les opérations d’accès aux contacts stockés.
• Le dépôt reçoit PDO au constructeur au lieu de créer la connexion.
• BaseDeDonnees fournira cette connexion ; sa configuration sera traitée ensuite.

Dans la prochaine leçon, vous configurerez la connexion PDO que le dépôt recevra.