Principe de responsabilité unique: chaque classe doit avoir une responsabilité, donc déplacer la logique métier vers les classes de services, utiliser les demandes de formulaire de validation et gérer les effets secondaires via des événements ou des travaux. 2. Principe ouvert / fermé: étendre les fonctionnalités sans modifier le code existant en utilisant des interfaces et une injection de dépendance, telles que la liaison de différentes passerelles de paiement dans le conteneur de service de Laravel. 3. Principe de substitution de Liskov: Assurez-vous que les classes des enfants maintiennent le contrat de comportement de leurs parents, en évitant les incohérences de paramètres ou de comportement dans les méthodes remplacées. 4. Principe de ségrégation de l'interface: Créez de petites interfaces focalisées comme UserFinder et UserUpDater afin que les clients ne dépendent que des méthodes qu'ils utilisent, améliorant la modularité. 5. Principe d'inversion de dépendance: dépendre des abstractions en injectant les interfaces dans des modules de haut niveau, permettant une liaison flexible des implémentations via le conteneur IOC de Laravel. L'application de ces principes dans Laravel améliore la maintenabilité, l'évolutivité et la testabilité en favorisant la séparation des préoccupations et la réduction du couplage, empêchant finalement les contr?leurs et les modèles de devenir monolithiques.

Les principes solides sont des concepts de conception fondamentaux orientés objet qui aident à créer un code maintenable, évolutif et testable. Laravel, étant un cadre PHP moderne construit sur des composants Symfony, fournit un excellent support pour la mise en ?uvre de ces principes. Voici comment vous pouvez appliquer chaque principe solide dans un projet Laravel.

1. Principe de responsabilité unique (SRP)

Une classe ne devrait avoir qu'une seule raison de changer.

Dans Laravel, il est courant de voir des contr?leurs ou des modèles gonflés en faire trop - gérer la logique HTTP, la logique métier, les requêtes de base de données et même l'envoi d'e-mails.

Comment appliquer SRP:

• Déplacez la logique commerciale des contr?leurs et des modèles.
  • Utilisez des cours de service pour la logique métier.
  • Utilisez des classes de demande de formulaire pour la validation.
  • Utilisez des événements / auditeurs ou des travaux pour les effets secondaires (par exemple, envoyer des e-mails).

Exemple:

 // app / services / userRegistrationsservice.php
Classe UserRegistrations Service
{
    Registre des fonctions publiques (Données Array $): utilisateur
    {
        $ user = user :: create ($ data);
        événement (nouvel utilisateur Inscrit ($ user));
        retourner $ utilisateur;
    }
}

Ensuite dans votre contr?leur:

 Public Function Store (UserRegistrationRequest $ demande, userRegistrationsService $ service)
{
    $ user = $ service-> registre ($ request-> valided ());
    return redirect () -> Route ('Users.show', $ utilisateur);
}

Cela maintient le contr?leur léger et délégue la responsabilité de manière appropriée.

2. Principe ouvert / fermé (OCP)

Les classes doivent être ouvertes pour l'extension, mais fermées pour la modification.

Cela signifie que vous devriez pouvoir ajouter de nouvelles fonctionnalités sans modifier le code existant.

Comment appliquer l'OCP dans Laravel:

• Utilisez des interfaces et une injection de dépendance .
• Tirez parti du conteneur de service de Laravel pour lier les implémentations.

Exemple:

 // définir une interface
Interface Paymentgateway
{
    Fonction publique Accueil (Montant Float $): bool;
}

// implémenter pour Stripe
Class Strepepayment implémente PaymentGateway {/ * ... * /}

// Mettez en ?uvre pour PayPal
classe PayPalPayment implémente Paytgateway {/ * ... * /}

Lier dans un fournisseur de services:

 $ this-> app-> bind (PaytGateway :: class, strepepayment :: class);

Vous pouvez maintenant changer d'implémentations sans modifier la classe consommée:

 Class CheckoutContrller
{
    Fonction publique __CONSTURT (PAYS PAYSGATEWAYS $ Gateway) {}

    Paye de la fonction publique (demande $ demande)
    {
        $ this-> gateway-> charge ($ request-> montant);
        // Aucun changement de code nécessaire si vous passez à PayPal plus tard
    }
}

Vous pouvez étendre les fonctionnalités en ajoutant de nouvelles passerelles, sans modifier celles existantes.

3. Principe de substitution de Liskov (LSP)

Les sous-types doivent être substituables à leurs types de base.

Si vous utilisez l'héritage (par exemple, les classes prolongées), assurez-vous que les classes des enfants ne cassent pas le comportement attendu du parent.

Comment suivre LSP à Laravel:

• évitez les méthodes de remplacement d'une manière qui modifie leur contrat.
• N'affaiblissez pas les conditions préalables et ne renforcez pas les limites postales dans les classes enfants.

Exemple: Si vous avez une classe NotificationSender de base, assurez-vous que tous les enfants (par exemple, EmailSender , SmsSender ) se comportent de manière prévisible lorsque send() est appelé.

éviter:

 La classe SMSSender étend NotificationsSender
{
    Fonction publique Envoyer ($ message, $ e-mail) // attend un e-mail, mais nous envoyons des SMS?
    {
        // Utilisation des paramètres non valide - viole le LSP
    }
}

Au lieu de cela, concevoir des interfaces cohérentes comportementales.

4. Principe de ségrégation de l'interface (ISP)

Les clients ne devraient pas être obligés de dépendre des interfaces qu'ils n'utilisent pas.

Au lieu de grandes interfaces génériques, créez des interfaces génériques plus petites et spécifiques.

Comment appliquer le FAI à Laravel:

• Ne créez pas une interface de référentiel massive avec chaque méthode.
• Diviser les interfaces par cas d'utilisation.

Exemple:

 Interface UserFinder
{
    Fonction publique FindById (int $ id) :? utilisateur;
    fonction publique findByEmail (String $ e-mail) :? utilisateur;
}

interface userupDater
{
    Mise à jour de la fonction publique (utilisateur de l'utilisateur $, array $ data): bool;
}

Maintenant, un service qui n'a besoin que des utilisateurs ne dépend que de UserFinder , et non des méthodes de mise à jour qu'il n'utilise pas.

Vous pouvez toujours avoir une mise en ?uvre de classe les deux:

 Classe EloquentiserRepository implémente UserFinder, userupDater
{
    // implémenter les deux
}

Mais les consommateurs ne dépendent que de ce dont ils ont besoin.

5. Principe d'inversion de dépendance (DIP)

Dépendent des abstractions, pas des concrétions.

Les modules de haut niveau (comme les contr?leurs ou les services) ne doivent pas dépendre directement de détails de bas niveau (comme des modèles éloquents ou des API spécifiques).

Comment appliquer une trempette dans Laravel:

• Utilisez les interfaces et le conteneur IOC de Laravel .
• Injectez des dépendances au lieu de les instanciation.

Exemple:

 Class UserController étend le contr?leur
{
    Fonction publique __construct (UserFinder protégé $ Finder) {}

    salon de la fonction publique ($ id)
    {
        $ user = $ this-> finder-> findById ($ id);
        return View ('users.show', compact ('utilisateur'));
    }
}

Lier l'implémentation:

 // appserviceprovider.php
Registre des fonctions publiques ()
{
    $ this-> app-> bind (userFinder :: class, eloventUserRepository :: class);
}

Maintenant, le contr?leur ne se soucie pas de la fa?on dont l'utilisateur est trouvé - seulement qu'il peut être trouvé.

Conseils bonus pour Laravel

• Utilisez des actions ou des taches : pour des opérations complexes, envisagez d'utiliser des classes à une seule action (par exemple, CreateOrderAction ) pour garder les choses conformes à SRP.
• Tirez parti des travaux et des auditeurs : déchargez les effets secondaires (par exemple, notifications, journalisation) pour des emplois en file d'attente ou des auditeurs d'événements.
• Services de référentiels : utilisez des référentiels pour abstraction d'accès aux données et des services pour orchestrer la logique.
• évitez les fa?ades dans la logique des affaires : préférez l'injection de dépendance aux fa?ades pour la testabilité et la clarté.

Réflexions finales

Appliquer un solide dans Laravel ne concerne pas les règles strictes - il s'agit d'écrire du code plus facile à tester, à changer et à évoluer. L'architecture de Laravel (conteneur de service, contrats, événements, emplois) rend naturel de suivre ces principes si vous structurez votre application pensivement.

Démarrez petit: nettoyez les contr?leurs, extraire la logique dans les services, utilisez des interfaces et laissez le conteneur de service faire le reste.

Fondamentalement, ne laissez pas les modèles ou les contr?leurs éloquents devenir un terrain de dumping pour tout.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!