Qu'est-ce qu'un modèle de conception ?
Un modèle de conception est un ensemble d'expériences de conception de code classifiées qui sont utilisées à plusieurs reprises et sont connues de la plupart des utilisateurs. En résumé, cela n’a rien à voir avec un langage spécifique, c’est une sorte de pensée.
Ce n'est qu'en maîtrisant la pensée orientée objet que vous pourrez mieux comprendre les modèles de conception, et vice versa.
Les modèles de conception sont de bonnes méthodes de programmation résumées par les programmeurs lors de la pratique du génie logiciel.
Il existe 23 modèles de conception au total.
L'essence de ces 23 modèles de conception est l'application pratique des principes de conception orientée objet et une compréhension complète de l'encapsulation, de l'héritage et du polymorphisme des classes, ainsi que des relations d'association et de combinaison des classes.
(Tutoriels vidéo associés recommandés : vidéo Java)
Classification des modèles de conception
1.
Modèles créatifs (5 types) : modèle singleton, modèle de méthode d'usine, modèle d'usine abstrait, modèle de constructeur, modèle de prototype. 2. Mode structurel Mode structurel (7 types) : mode adaptateur, mode décorateur, mode proxy, mode apparence, mode pont, mode combinaison, mode poids mouche. 3. Modèles comportementaux Modèles comportementaux (11 types) : modèle de stratégie, modèle de méthode modèle, modèle d'observateur, sous-modèle itératif, modèle de chaîne de responsabilité, modèle de commande, modèle de mémo, État modèle, modèle de visiteur, modèle de médiateur, modèle d'interprète.Six principes des modèles de conception
Principes généraux : Principe d'ouverture et de fermeture Ouvert pour extension, fermé pour modification. Lorsque le programme doit être étendu, le code original ne peut pas être modifié, mais le code original doit être étendu pour obtenir un effet remplaçable à chaud. Le résumé en une phrase est donc le suivant : afin de rendre le programme évolutif et facile à maintenir et à mettre à niveau. Pour obtenir cet effet, nous devons utiliser des interfaces et des classes abstraites, etc. Nous le mentionnerons plus tard dans la conception spécifique. 1. Principe de responsabilité unique Ne pas avoir plus d'une raison pour les changements de classe, c'est-à-dire que chaque classe doit mettre en œuvre une seule responsabilité, sinon la classe doit être divisée. 2. Principe de substitution de Liskov Partout où une classe de base peut apparaître, une sous-classe peut certainement apparaître. Le principe de substitution de Liskov est la pierre angulaire de la réutilisation de l'héritage. Ce n'est que lorsque la classe dérivée peut remplacer la classe de base et que la fonction de l'unité logicielle n'est pas affectée que la classe de base peut être véritablement réutilisée et que la classe dérivée peut également en ajouter de nouvelles. la base du comportement de la classe de base. Le principe de substitution de Liskov est un complément au principe « ouvert-fermé ». L'étape clé dans la réalisation du principe « ouvert-fermé » est l'abstraction. La relation d'héritage entre les classes de base et les sous-classes est l'implémentation spécifique de l'abstraction, donc le principe de substitution de Liskov est une spécification des étapes spécifiques pour réaliser l'abstraction. Dans le principe de substitution de Liskov, les sous-classes doivent essayer de ne pas écraser ou surcharger les méthodes de la classe parent. Étant donné que la classe parent représente une structure définie et interagit avec le monde extérieur via cette interface standardisée, les sous-classes ne doivent pas la détruire par hasard. 3. Principe d'inversion des dépendances La programmation orientée interface repose sur l'abstraction plutôt que sur le concret. Lorsqu'une classe concrète est utilisée lors de l'écriture de code, elle n'interagit pas avec la classe concrète, mais avec l'interface supérieure de la classe concrète. 4. Principe de ségrégation des interfaces Il n'y a aucune méthode dans chaque interface qui ne soit pas utilisée par les sous-classes mais qui doit être implémentée. Sinon, l'interface doit être divisée. Il est préférable d'utiliser plusieurs interfaces isolées plutôt que d'utiliser une seule interface (plusieurs méthodes d'interface combinées en une seule interface). 5. Principe de Déméter (Principe de Déméter) Moins une classe en sait sur les classes dont elle dépend, mieux c'est. Quelle que soit la complexité de la classe dépendante, la logique doit être encapsulée à l’intérieur de la méthode et fournie à l’extérieur via la méthode publique. De cette façon, lorsque la classe dépendante change, l’impact sur la classe sera minime. Une autre expression du principe le moins connu est : ne communiquez qu'avec des amis directs. Tant qu’il existe une relation de couplage entre les classes, on parle alors de relation d’amitié. Le couplage est divisé en dépendance, association, agrégation, combinaison, etc. Nous appelons les classes qui apparaissent dans les variables membres, les paramètres de méthode et les valeurs de retour de méthode amis directs. Les variables locales et les variables temporaires ne sont pas des amis directs. Nous exigeons que les classes inconnues n'apparaissent pas comme variables locales dans la classe. 6. Principe de réutilisation composite Essayez d'abord d'utiliser la synthèse/agrégation au lieu d'utiliser l'héritage. Tutoriel recommandé :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!