1) Le modèle singleton
contient uniquement une classe spéciale appelée classe singleton dans sa structure de base. Le mode singleton peut garantir qu'il n'y a qu'une seule instance d'une classe dans le système et que l'instance est facilement accessible depuis le monde extérieur, facilitant ainsi le contrôle du nombre d'instances et économisant les ressources du système.
Scénario d'application : Si vous espérez qu'un seul objet d'une certaine classe puisse exister dans le système, le mode singleton est la meilleure solution.
2) Modèle d'usine
Le modèle d'usine fournit principalement une interface pour créer des objets.
Les scénarios d'application sont les suivants :
a. Il est impossible de prédire quelle instance de classe doit être créée lors du codage.
b. Le système ne doit pas s'appuyer sur les détails de la façon dont les instances de classe de produits sont créées, combinées et exprimées.
3) Modèle de stratégie
Modèle de stratégie : définit une famille d'algorithmes et les encapsule séparément afin qu'ils puissent être remplacés les uns par les autres. Ce mode permet aux modifications apportées à l'algorithme d'être indépendantes des clients utilisant l'algorithme.
Les scénarios d'application sont les suivants.
a. Il existe de nombreuses solutions pour réaliser une chose.
b. Je peux décider quelle implémentation utiliser à tout moment.
c. D'autres plans pourraient être ajoutés à l'avenir.
D. Le modèle stratégique empêche les modifications apportées au plan d'affecter les clients qui utilisent le plan.
L'exemple de scénario commercial est le suivant.
Les opérations du système doivent être enregistrées. Les journaux sont généralement enregistrés dans la base de données pour faciliter la gestion ultérieure. Cependant, des erreurs peuvent survenir lors de l'enregistrement des journaux dans la base de données. Par exemple, si la base de données ne peut pas être connectée temporairement, enregistrez-la d'abord dans la base de données. déposer. Il existe deux algorithmes pour écrire des journaux dans la base de données et dans les fichiers, mais l'appelant s'en fiche et n'est responsable que de l'écriture.
4) Modèle d'observateur
Le modèle d'observateur, également connu sous le nom de modèle de publication/abonnement, définit des dépendances un à plusieurs entre les objets Lorsqu'un objet change d'état, toutes ses dépendances seront notifiées et automatiquement renouvelées.
Les scénarios d'application sont les suivants :
a. La mise à jour de l'état d'un objet nécessite des mises à jour simultanées d'autres objets, et le nombre d'autres objets est dynamiquement variable.
b. Les objets doivent uniquement informer les autres objets de leurs propres mises à jour sans connaître les détails des autres objets.
5) Modèle d'itérateur
Le modèle d'itérateur fournit un moyen d'accéder séquentiellement aux éléments individuels d'un objet agrégé sans exposer la représentation interne de l'objet.
Les scénarios d'application sont les suivants :
Lorsque vous avez besoin d'accéder à un objet de collection et que vous devez le parcourir quels que soient ces objets, vous devez envisager d'utiliser le modèle itérateur. En fait, le conteneur stl est un bon exemple de modèle d'itérateur.
6) Modèle de méthode modèle
Le modèle de méthode modèle définit le squelette d'un algorithme en fonctionnement et reporte certaines étapes aux sous-classes. Les méthodes modèles permettent aux sous-classes de redéfinir un algorithme sans modifier sa structure.
Les scénarios d'application sont les suivants : pour certaines fonctions, différents effets sont affichés sur différents objets, mais le cadre fonctionnel est le même.
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!