Modèles de conception

Le modèle de conception (modèle de conception) est un ensemble de résumés classifiés et catalogués de l'expérience de conception de code utilisé à plusieurs reprises et connu de la plupart des gens. Le but de l'utilisation de modèles de conception est de réutiliser le code, de le rendre plus facile à comprendre par les autres et de garantir sa fiabilité. Il ne fait aucun doute que les modèles de conception sont gagnant-gagnant pour nous-mêmes, pour les autres et pour le système ; les modèles de conception font de l'écriture de code une véritable ingénierie. Les modèles de conception sont la pierre angulaire du génie logiciel, tout comme la structure d'un bâtiment.

Les Design patterns (design patterns anglais) sont des solutions à des problèmes récurrents en conception orientée objet. Ce terme a été introduit en informatique dans le domaine de la conception architecturale dans les années 1990 par Erich Gamma et d'autres. La signification de ce terme est controversée. Les algorithmes ne sont pas des modèles de conception, car ils s’attaquent à la résolution de problèmes plutôt qu’à des problèmes de conception. Les modèles de conception décrivent généralement un ensemble de classes et d’objets qui interagissent étroitement les uns avec les autres. Les modèles de conception fournissent un langage commun pour discuter de la conception de logiciels afin que l'expérience de conception de concepteurs qualifiés puisse être saisie par les novices et les autres concepteurs. Les modèles de conception fournissent également des objectifs pour la refactorisation logicielle.

Avec l'intérêt croissant pour les modèles de conception dans la communauté du développement logiciel, certaines monographies connexes ont été publiées, des séminaires correspondants ont été organisés régulièrement et Ward Cunningham a inventé WikiWiki pour échanger des expériences en matière de modèles de conception.

Conseils : Ce tutoriel vous expliquera le concept de modèles de conception étape par étape à travers des exemples Java. Vous devez donc savoir quelque chose sur les connaissances Java.

Format d'expression

Le format d'expression d'un modèle de conception de logiciel dépend de l'auteur, et la division et le nom seront différents. Le format des modèles de description GoF couramment utilisés est grossièrement divisé en les parties suivantes :

• Nom du modèle : chaque modèle a son propre nom, et le nom du modèle nous permet de discuter de notre conception.

• Problème : Il existe des occasions spécifiques qui reviennent lors de la conception de systèmes orientés objet et cela nous amène à adopter un certain modèle.

• Solution : La solution au problème ci-dessus, son contenu donne les différents composants de la conception, la relation entre eux, la répartition des responsabilités et le mode de collaboration.

• Alias : Un modèle peut avoir plusieurs noms. Ces noms doivent être notés dans cette section.

• Motivation : Auquel cas ce mode est utilisé relève de la responsabilité de la solution proposée dans cette section (y compris le problème et les tenants et aboutissants).

• Applicabilité : à quelles situations le motif est applicable, à l'arrière-plan du motif, etc.

• Structure : Cette partie des diagrammes de classes et des diagrammes d'interaction couramment utilisés illustre ce modèle.

• Participants : Cette section fournit une liste des classes et des objets utilisés dans ce modèle et les rôles qu'ils jouent dans la conception.

• Coopération : décrit l'interaction entre les classes et les objets dans ce mode.

• Impact : L'impact de l'adoption de ce modèle sur d'autres parties du système logiciel, comme l'impact sur l'évolutivité et la portabilité du système. L’impact comprend également les impacts négatifs. Cette section doit décrire les résultats, les effets secondaires et les compromis liés à l'utilisation de ce modèle.

• Mise en œuvre : cette section doit décrire la mise en œuvre du modèle, les solutions partielles pour le modèle, les technologies possibles pour la mise en œuvre du modèle ou les suggestions. méthode de modèle d’implémentation.

• Exemple : Décrivez brièvement comment utiliser les modèles dans les langages de programmation.

• Applications connues : exemples de mise en œuvre connus dans l'industrie.

• Modèles associés : Cette section comprend d'autres modèles associés, ainsi que les différences par rapport à d'autres modèles similaires.

Astuce : Notre tutoriel sur les modèles de conception vous aidera à tout savoir sur les modèles de conception. Si vous avez des questions, rendez-vous sur la Communauté chinoise PHP pour poser vos questions, et des internautes enthousiastes y répondront pour vous.

Principes des modèles

Tout le monde commence à prêter attention aux modèles de conception. Alors, pourquoi utilisons-nous des modèles de conception ? Pourquoi devrions-nous concevoir avec autant de modèles de conception ?

Pour être honnête, je ne l’ai pas vraiment compris avant. Le simple fait de regarder tout le monde répéter « Modèle de conception » me fait me sentir un peu faible. J'ai donc acheté un exemplaire du patron de conception "Gang of Four", et il s'est avéré que je ne le comprenais pas du tout : il me semblait le comprendre quand je le lisais, mais je l'ai oublié au bout d'un moment. C'est peut-être parce que je suis relativement "stupide" :)) Récemment, j'ai eu quelques idées. "Il vaut mieux s'amuser seul que s'amuser ensemble", j'aimerais le partager avec vous, et j'espère que vous pourrez me donner quelques conseils

Pourquoi devrions-nous prôner le "Design Pattern" ? La raison fondamentale est de réutiliser le code et d’augmenter la maintenabilité.

Alors, comment pouvons-nous parvenir à réutiliser le code ? Le monde OO reprend plusieurs principes de ses prédécesseurs : le principe « Open Closed Principal », le principe de substitution de Liskov et le principe de synthèse et de réutilisation. Les modèles de conception mettent en œuvre ces principes pour parvenir à la réutilisation du code et augmenter la maintenabilité.

• Principe Ouvert-Fermé

Ce principe a été proposé par "Bertrand Meyer". Le texte original est : « Les entités logicielles doivent être ouvertes pour extension, mais fermées pour modification ». C'est-à-dire que le module doit être ouvert pour extension mais fermé pour modification. Les modules doivent essayer d'être étendus sans modifier le code original (« original », faisant référence au code original). Alors comment s’étendre ? Regardons le « modèle d'usine » : supposons qu'il y ait un gars à Zhongguancun qui vend des disques piratés et des films pornographiques, et que nous concevions un « logiciel de gestion des ventes de disques » pour lui. Nous devrions d'abord concevoir une interface "CD". Comme le montre l'image : [pre]______________|<>|| CD ||____________||+Sell() |||____________|[/pre] Et les disques piratés et les films pornographiques sont ses sous-catégories. Le garçon gère ces disques via "DiscFactory". Le code est :

publicclassDiscFactory{
publicstatic光盘
getDisc(Stringname){
return(光盘)Class.forName(name).getInstance();
}
}

Quelqu'un veut acheter un disque piraté, comment faire ?

public class boy { public static void main(String【】 args){ CD d=DiscFactory.getDisc("Pirate Disc"); CD.Sell( } }

Si un jour, la conscience de ce garçon le découvre, Commencez à vendre des logiciels authentiques. Ce n'est pas grave, il suffit de créer une autre sous-catégorie de « CD » appelée « logiciel authentique ». Pas besoin de modifier la structure et le code d'origine. Et ça ? Ouvert pour extension, fermé pour modification. "Principe ouvert-fermé" Le modèle d'usine étend des produits spécifiques. Certains projets peuvent nécessiter plus d'évolutivité. Si vous souhaitez étendre cette "usine", elle devient le "modèle d'usine abstrait".

• Principe de substitution de Richter

Le principe de substitution Liskov a été proposé par "Barbara Liskov". Si la classe parent est appelée, elle peut être exécutée si elle est transformée en sous-classe. Par exemple : CD d=nouveau disque piraté(); d. sell(); Si vous souhaitez changer la catégorie "disque piraté" en catégorie "film pornographique", pas de problème, il peut fonctionner complètement. Le compilateur Java vérifie si le programme respecte le principe de substitution de Liskov. Vous souvenez-vous encore d’un principe de l’héritage Java ? Les droits d'accès de la méthode override de la sous-classe ne peuvent pas être inférieurs aux droits d'accès de la méthode correspondante de la classe parent. Par exemple, l'autorisation d'accès de la méthode « Vendre » dans « CD » est « publique », alors la méthode « Vendre » dans « Pirate Disc » et « Raw Film » ne peut pas être protégée ou privée, et la compilation ne réussira pas. Pourquoi faut-il qu'il en soit ainsi ? Pensez-y : si la méthode de « vente » des « disques piratés » est privée. Alors le code suivant ne peut pas être exécuté : CD d=new pirated disk(); d.sell(); On peut dire que le principe de substitution de Liskov est une base pour l'héritage et la réutilisation.

• Le principe de composition et de réutilisation

signifie utiliser moins d'héritage et plus de relations de composition. Une fois, j'ai écrit un programme comme celui-ci : il y a plusieurs classes qui doivent gérer la base de données, j'écris donc une classe pour les opérations de base de données, puis d'autres classes qui gèrent la base de données en héritent. En conséquence, plus tard, j'ai modifié une méthode de la classe d'opération de base de données, et toutes les classes ont dû être modifiées. "Un mouvement affecte tout le corps" ! L'orientation objet consiste à limiter les fluctuations à la plus petite plage possible.

En Java, vous devriez essayer de programmer pour l'interface plutôt que pour les classes d'implémentation. De cette façon, modifier une sous-classe n’affectera pas le code qui appelle ses méthodes. Laissez chaque catégorie avoir le moins de contacts possible avec les autres : « Ne parlez pas aux étrangers ». De cette façon, si la porte de la ville prend feu, cela ne nuira pas aux poissons de l'étang. Ce n'est que lorsque l'évolutivité et la maintenabilité pourront être améliorées

Après avoir compris ces principes, puis examiné le modèle de conception, il s'agit simplement de savoir comment mettre en œuvre ces principes sur des problèmes spécifiques. Zhang Wuji a appris le Tai Chi, a oublié tous les mouvements et a vaincu les « Deux anciens Xuan Mi ». On a dit qu'il « n'avait aucun mouvement en tête ». Les modèles de conception peuvent être décrits comme des astuces. Si vous apprenez d'abord tous les modèles, puis oubliez tous les modèles et faites ce que vous voulez, cela peut être appelé l'état le plus élevé de l'OO. Haha, drôle, drôle ! (JR)

Principe d'inversion de dépendance L'abstraction ne devrait pas dépendre des détails. Les détails doivent être programmés selon le

• Principe d'inversion de dépendance

pour les interfaces, et non la programmation d'implémentation. Lors de la transmission de paramètres ou dans des relations d'agrégation combinées, essayez de référencer des classes de niveau supérieur. La raison principale est que divers objets concrets peuvent être créés dynamiquement lors de la construction d'objets. Bien sûr, si certaines classes concrètes sont relativement stables, il n'est pas nécessaire de créer une classe abstraite comme classe parent. C'est superflu. services. Exemple, chaque

• Principe d'isolation d'interface

Une sorte de rôle, ni plus, ni moins, ne fais pas ce que tu ne devrais pas faire, fais ce que tu dois faire, classe abstraite, classe abstraite. il n'y aura pas d'instances

• Classe abstraite

Les classes sont héritées par les sous-classes et contiennent généralement des attributs et des méthodes communes à ce système. Remarque : Dans une bonne relation d'héritage, seuls les nœuds feuilles doivent être des classes concrètes et les autres nœuds doivent être des classes abstraites, ce qui signifie que les classes concrètes ne sont pas héritées. Mettez autant de code commun que possible dans des classes abstraites. 7 Principe de la loi du minimum de connaissances de Déméter. Ne parlez pas à des inconnus.

Contenu couvert dans ce manuel de didacticiel de modèle de conception

Ce didacticiel de modèle de conception couvre l'introduction de tous les modèles de conception, y compris le modèle d'usine, le modèle d'usine abstrait, le modèle Singleton et le modèle de constructeur (modèle de constructeur), le modèle de prototype (modèle de prototype), etc.

Conseils : Chaque chapitre de ce didacticiel contient de nombreux exemples Java, qui vous aideront à mieux apprendre et comprendre les modèles de conception.