User registered!
"; } else { echo "Email already exists.
"; } } else { echo "Invalid email.
"; } } ?> ``` ### La bonne approche : séparation des préoccupations Nous refactorisons cela en séparant l'interaction avec la base de données (Repository), les règles métier/validation (Controller) et la présentation visuelle (Blade/Template). ```php // app/Repositories/UserRepository.php declare(strict_types=1); namespace App\Repositories; use PDO; class UserRepository { private PDO $pdo; public function __construct(PDO $pdo) { $this->pdo = $pdo; } public function findByEmail(string $email): ?array { $stmt = $this->pdo->prepare("SELECT * FROM users WHERE email = :email"); $stmt->execute(['email' => $email]); return $stmt->fetch() ?: null; } public function create(string $email): bool { $stmt = $this->pdo->prepare("INSERT INTO users (email) VALUES (:email)"); return $stmt->execute(['email' => $email]); } } ``` ```php // app/Http/Controllers/RegisterController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Repositories\UserRepository; use InvalidArgumentException; class RegisterController { private UserRepository $userRepository; public function __construct(UserRepository $userRepository) { $this->userRepository = $userRepository; } public function register(array $data): string { $email = $data['email'] ?? ''; if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { throw new InvalidArgumentException("Invalid email format."); } if ($this->userRepository->findByEmail($email) !== null) { return "Email already exists."; } $this->userRepository->create($email); return "User registered!"; } } ``` --- ## L'Objet Dieu (God Object) Un **Objet Dieu** (God Object) est une classe monolithique qui en sait trop ou en fait trop. Il concentre toute l'intelligence de l'application, violant ainsi le **principe de responsabilité unique (SRP)**. Les autres classes du système deviennent de simples conteneurs de données passifs (modèles anémiques) contrôlés par cette classe géante. ### La mauvaise approche : un OrderManager monolithique Ici, une seule classe gère la connexion à la passerelle de paiement, l'enregistrement en base de données, l'envoi d'e-mails, le calcul des remises et la génération de PDF. ```php // app/Services/OrderManager.php declare(strict_types=1); namespace App\Services; class OrderManager { public function processOrder(array $orderData): void { // 1. Calculate discount $total = $orderData['price']; if ($orderData['coupon'] === 'SUMMER') { $total *= 0.9; } // 2. Save order to database $db = new \PDO("mysql:host=localhost;dbname=shop", "root", ""); $stmt = $db->prepare("INSERT INTO orders (total, user_id) VALUES (?, ?)"); $stmt->execute([$total, $orderData['user_id']]); // 3. Process payment via Stripe $stripe = new \Stripe\StripeClient('sk_test_key'); $stripe->charges->create([ 'amount' => (int)($total * 100), 'currency' => 'usd', 'source' => $orderData['token'], ]); // 4. Generate PDF invoice $pdf = new \FPDF(); $pdf->AddPage(); $pdf->Write(10, "Invoice total: " . $total); $pdf->Output('F', "/invoices/order.pdf"); // 5. Send email notification mail($orderData['email'], "Order Success", "Your order total is " . $total); } } ``` ### La bonne approche : services découplés Nous refactorisons en déléguant chaque tâche du domaine à un composant dédié, faisant ainsi de la classe gestionnaire un coordinateur léger. ```php // app/Services/OrderService.php declare(strict_types=1); namespace App\Services; use App\Repositories\OrderRepository; use App\Services\Payment\PaymentGatewayInterface; use App\Services\Notification\NotificationInterface; use App\Services\Invoice\InvoiceGeneratorInterface; class OrderService { private OrderRepository $repository; private DiscountCalculator $discountCalculator; private PaymentGatewayInterface $paymentGateway; private InvoiceGeneratorInterface $invoiceGenerator; private NotificationInterface $notifier; public function __construct( OrderRepository $repository, DiscountCalculator $discountCalculator, PaymentGatewayInterface $paymentGateway, InvoiceGeneratorInterface $invoiceGenerator, NotificationInterface $notifier ) { $this->repository = $repository; $this->discountCalculator = $discountCalculator; $this->paymentGateway = $paymentGateway; $this->invoiceGenerator = $invoiceGenerator; $this->notifier = $notifier; } public function checkout(array $orderData): void { $total = $this->discountCalculator->calculate($orderData['price'], $orderData['coupon']); $order = $this->repository->save($total, $orderData['user_id']); $this->paymentGateway->charge($total, $orderData['token']); $invoicePath = $this->invoiceGenerator->generate($order); $this->notifier->sendSuccessNotification($orderData['email'], $total, $invoicePath); } } ``` --- ## Le Marteau d'or (Golden Hammer) Le **Marteau d'or** (Golden Hammer) est la fausse croyance selon laquelle une technologie ou un patron de conception favori s'applique universellement : *« Si tout ce que vous avez est un marteau, tout ressemble à un clou. »* En PHP, cela se produit souvent lorsque les développeurs tentent d'utiliser des patrons de structure ou de comportement complexes (comme State ou Visitor) pour des tâches simples, ce qui entraîne une prolifération inutile de classes, ou lorsqu'ils utilisent un moteur de base de données (comme Elasticsearch ou Redis) pour des tâches qui pourraient être facilement réalisées directement en SQL. ### La mauvaise approche : forcer le patron State pour une simple vérification d'âge Un développeur souhaite vérifier si un utilisateur est autorisé à acheter de l'alcool. Au lieu d'une simple condition, il construit tout un mécanisme basé sur le patron de conception State, avec de multiples interfaces et classes concrètes. ```php // app/Validation/AgeValidator.php declare(strict_types=1); namespace App\Validation; interface AgeStateInterface { public function canPurchaseAlcohol(): bool; } class UnderageState implements AgeStateInterface { public function canPurchaseAlcohol(): bool { return false; } } class AdultState implements AgeStateInterface { public function canPurchaseAlcohol(): bool { return true; } } class AgeValidator { private AgeStateInterface $state; public function __construct(int $age) { $this->state = $age >= 18 ? new AdultState() : new UnderageState(); } public function check(): bool { return $this->state->canPurchaseAlcohol(); } } ``` ### La bonne approche : rester simple (KISS) Les patrons de conception ajoutent de la complexité et une charge cognitive. Si la logique métier est simple, écrivez-la simplement. ```php // app/Validation/AgeValidator.php declare(strict_types=1); namespace App\Validation; class AgeValidator { private const ALCOHOL_MINIMUM_AGE = 18; public static function canPurchaseAlcohol(int $age): bool { return $age >= self::ALCOHOL_MINIMUM_AGE; } } ``` > [!NOTE] > **Utilisez les patrons de conception lorsque la complexité le justifie** : Les design patterns sont conçus pour gérer des exigences changeantes et une grande complexité. Si votre logique d'état ne comporte qu'une seule condition simple qui ne changera jamais, l'utilisation d'un patron de conception relève de la sur-conception (over-engineering). --- ## L'optimisation prématurée (Premature Optimization) L'**Optimisation prématurée** (Premature Optimization) consiste à optimiser les performances du code avant d'avoir la preuve concrète (via des outils de profilage comme Xdebug ou Blackfire) qu'il représente réellement un goulot d'étranglement. Cela conduit à un code complexe et illisible écrit pour économiser quelques microsecondes, tout en ignorant des requêtes de base de données lentes ou des requêtes d'API externes qui prennent des centaines de millisecondes. ### La mauvaise approche : micro-optimisations obscurcies Un développeur évite les fonctions PHP claires et utilise des recherches de chaînes imbriquées ainsi que des opérations au niveau du bit (bitwise) pour analyser les chaînes de configuration, pensant que c'est plus rapide. ```php // app/Config/Parser.php declare(strict_types=1); namespace App\Config; class Parser { // Cryptic string manipulation to save CPU cycles public function parse(string $data): array { $pos = strpos($data, ':'); if ($pos === false) return []; $key = substr($data, 0, $pos); $val = substr($data, $pos + 1); // Bitwise flag check representing boolean configuration $isFlagged = (int)$val & 1; return [$key => (bool)$isFlagged]; } } ``` ### La bonne approche : privilégier la lisibilité du code Écrivez un code facile à lire, à tester et à maintenir. Si des problèmes de performance surviennent, effectuez d'abord un profilage (profiling), puis optimisez là où se trouvent les goulots d'étranglement. ```php // app/Config/Parser.php declare(strict_types=1); namespace App\Config; class Parser { public function parse(string $jsonString): array { $decoded = json_decode($jsonString, true); if (json_last_error() !== JSON_ERROR_NONE) { return []; } return $decoded; } } ``` --- ## Le Culte du cargo (Cargo Cult) & la programmation copier-coller La **programmation Culte du cargo** (Cargo Cult Programming) est la pratique consistant à copier des patrons de code, des structures ou des méthodologies sans comprendre *pourquoi* ils sont utilisés ni quel problème ils résolvent. Un exemple classique en PHP consiste à envelopper les modèles Eloquent de Laravel dans une couche Repository vide parce que « une bonne architecture nécessite des dépôts », même si Eloquent implémente déjà les patrons Active Record et Query Builder. ### La mauvaise approche : enveloppe d'abstraction Repository vide Ce dépôt d'enveloppement (wrapper repository) se contente de copier les méthodes d'Eloquent, n'apportant aucune abstraction ni valeur ajoutée, tout en doublant le nombre de classes à maintenir. ```php // app/Repositories/PostRepositoryInterface.php declare(strict_types=1); namespace App\Repositories; interface PostRepositoryInterface { public function find(int $id); public function create(array $data); } // app/Repositories/EloquentPostRepository.php declare(strict_types=1); namespace App\Repositories; use App\Models\Post; class EloquentPostRepository implements PostRepositoryInterface { public function find(int $id) { return Post::find($id); } public function create(array $data) { return Post::create($data); } } ``` ### La bonne approche : utiliser directement Active Record ou créer de véritables abstractions Si votre dépôt n'isole pas le client du mécanisme de persistance (par exemple en renvoyant de toute façon des modèles ou des requêtes Eloquent brutes), abandonnez-le et utilisez directement Eloquent. ```php // app/Http/Controllers/PostController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Models\Post; use Illuminate\Http\JsonResponse; class PostController { public function show(int $id): JsonResponse { // Use active record pattern directly $post = Post::findOrFail($id); return response()->json($post); } } ``` > [!TIP] > **Quand utiliser des dépôts (repositories)** : Utilisez-les lorsque vous implémentez une logique de domaine complexe qui doit rester indépendante de l'ORM (par exemple dans le cadre du Domain-Driven Design), ou lorsque vous construisez des requêtes personnalisées réutilisables que vous souhaitez tester de manière isolée. --- ## Erreurs courantes 1. **Forcer l'utilisation de patrons partout** : Implémenter des patrons de conception dans de simples projets CRUD. 2. **Écrire des classes dieux (God Classes)** : Laisser une classe d'aide (helper) ou de gestion (manager) grandir indéfiniment au lieu de la diviser en petits services cohérents. 3. **Optimiser sans profiler** : Réécrire des boucles PHP propres sous forme d'algorithmes complexes parce que vous « suspectez » qu'elles sont lentes, alors que la base de données exécute des requêtes sans index. 4. **Copier aveuglément** : Copier des patrons d'entreprise avancés (comme CQRS, Event Sourcing ou des couches de dépôt) dans de simples projets MVC simplement parce qu'ils sont populaires sur Internet. --- ## Aide-mémoire / Checklist 1. **Vérification SRP (responsabilité unique) :** Votre classe a-t-elle plus d'une raison de changer ? Si oui, divisez-la. 2. **Principe KISS :** Une simple condition `if` ou une fonction d'aide peut-elle remplacer une hiérarchie POO complexe ? 3. **Profilage des performances :** Avez-vous profilé votre application à l'aide de Xdebug ou de Blackfire avant d'appliquer des micro-optimisations ? 4. **Abstraction à valeur ajoutée :** Votre dépôt ou votre couche d'abstraction masque-t-il réellement les détails d'implémentation, ou s'agit-il simplement d'une enveloppe redundante ? --- ## Résumé Les anti-patterns de conception sont des pièges courants qui mènent à des logiciels rigides et fragiles. Le **Code Spaghetti** provient d'un manque de séparation des préoccupations. Les **Objets Dieux** regroupent trop de responsabilités. Le **Marteau d'or** impose de mauvaises solutions aux problèmes. L'**Optimisation prématurée** privilégie les micro-performances au détriment de la lisibilité. Le **Culte du cargo** duplique les structures sans comprendre leur valeur architecturale. Gardez le code simple et clair, et n'ajoutez des patrons de conception que lorsque la complexité l'exige. --- ## Quiz d'auto-évaluation ### Question 1 : Quel principe SOLID est directement violé lorsqu'une classe agit comme un « Objet Dieu » (God Object) ? - A) Principe ouvert/fermé (OCP) - B) Principe de substitution de Liskov (LSP) - C) Principe de responsabilité unique (SRP)