Design pattern

Un modèle de conception est la forme réutilisable d’une solution à un problème de conception. L’idée a été introduite par l’architecte Christopher Alexander et a été adaptée pour diverses autres disciplines, notamment l’informatique.

Modèles de conception de logiciels
Les modèles de conception de logiciels sont des propositions de solutions générales qui ont été développées pour résoudre des problèmes similaires fréquemment rencontrés lors de la conception de logiciels. Bien que les modèles de conception de logiciel soient généralement définis indépendamment des langages de programmation, les modèles de conception de logiciel adaptés aux langages de programmation orientés objet sont plus communément connus. Ces modèles montrent les relations et les interactions entre les objets et les classes. Le programmeur peut personnaliser un motif de conception en regardant le problème dans sa main.

Détails
Une collection organisée de modèles de conception qui se rapportent à un domaine particulier est appelée un langage de modèle. Ce langage donne une terminologie commune pour discuter des situations auxquelles les concepteurs sont confrontés.

Les éléments de ce langage sont des entités appelées patterns. Chaque modèle décrit un problème qui survient encore et encore dans notre environnement, puis décrit le cœur de la solution à ce problème, de telle sorte que vous pouvez utiliser cette solution un million de fois, sans jamais le faire deux fois de la même manière. . – Christopher Alexander

Documenter un modèle nécessite d’expliquer pourquoi une situation particulière cause des problèmes, et comment les composants du modèle sont liés les uns aux autres pour donner la solution. Christopher Alexander décrit les problèmes de conception courants comme découlant de «forces conflictuelles» – comme le conflit entre le fait de vouloir qu’une pièce soit ensoleillée et la volonté de ne pas surchauffer les après-midi d’été. Un motif ne dirait pas au concepteur combien de fenêtres mettre dans la pièce; au lieu de cela, il proposerait un ensemble de valeurs pour guider le concepteur vers une décision qui convient le mieux à son application particulière. Alexander, par exemple, suggère que suffisamment de fenêtres devraient être incluses pour diriger la lumière tout autour de la pièce. Il considère que c’est une bonne solution parce qu’il croit que cela augmente la jouissance de la pièce par ses occupants. D’autres auteurs pourraient arriver à des conclusions différentes s’ils accordent une plus grande valeur aux coûts de chauffage ou aux coûts matériels. Ces valeurs, utilisées par l’auteur du modèle pour déterminer quelle solution est la meilleure, doivent également être documentées dans le modèle.

La documentation de modèle devrait également expliquer quand elle est applicable. Puisque deux maisons peuvent être très différentes les unes des autres, un modèle de conception pour les maisons doit être assez large pour s’appliquer à chacune d’entre elles, mais pas si vague que cela n’aide pas le concepteur à prendre des décisions. La gamme de situations dans lesquelles un modèle peut être utilisé est appelée son contexte. Quelques exemples pourraient être « toutes les maisons », « toutes les maisons à deux étages », ou « tous les endroits où les gens passent du temps ».

Par exemple, dans le travail de Christopher Alexander, les arrêts d’autobus et les salles d’attente dans un centre de chirurgie sont tous deux dans le contexte du modèle «A PLACE TO WAIT».

Classes de motifs de conception
Le livre Pattern Patterns de Quadruple Gang (ISBN 0-201-63361-2) distingue trois modèles de motifs de design, mais il n’y a pas de critère pointu qui les sépare les uns des autres.

Patrons de création
Les modèles de création fournissent des suggestions sur la façon de créer des objets logiciels (ou, en d’autres termes, des instances de classe). L’idée est qu’un bon logiciel doit être conçu indépendamment de la façon dont les objets qu’il contient sont créés. En d’autres termes, où et comment les objets sont créés n’affecte pas le fonctionnement du logiciel auquel ils appartiennent; les nouvelles fonctionnalités ne devraient pas être ajoutées et les problèmes avec les changements.

Au fur et à mesure que les systèmes logiciels évoluent, la composition de l’objet acquiert plus d’importance que l’héritage de classe. La raison en est que les conceptions basées sur la définition de comportements de base simples pour les systèmes logiciels sont plus flexibles que les conceptions basées sur un comportement fixe. En d’autres termes, l’ajout de comportements à des objets en tant que combinaison permet de modifier le comportement ultérieur en fonction du développement du logiciel. Dans ce cas, une conception basée sur les exigences comportementales de base du logiciel développé permet d’utiliser des comportements différents ou plus complexes sans modifier les interfaces objet.

Cependant, il est plus difficile d’échantillonner des objets qui fournissent un comportement de base par le biais de combinaisons d’objectifs, ou de créer des objets à partir de classes dérivées en héritant ou en modifiant un comportement. Les modèles de création incluent des modèles de logiciel qui peuvent être utilisés pour surmonter ces difficultés.

Les modèles de création stockent dans le système logiciel les classes concrètes utilisées dans l’instance d’objet ainsi que la manière dont ces instances sont créées et assemblées.

Méthode d’usine
En héritant de la façon dont l’objet le crée sous l’interface unique utilisée pour la création d’objet, il laisse les fonctions de création d’objet dans l’interface en les laissant aux sous-classes.

Exemple (modèle prototype)
Lors de la création d’objets à partir de classes complexes et / ou coûteuses, ils permettent de créer de nouveaux objets en les échantillonnant à partir de leurs existants au lieu d’être créés depuis le début. De cette manière, de nouveaux objets sont facilement créés et les ressources ne sont pas inutilement occupées.

Modèle d’usine abstraite
Une seule interface permet de créer une famille d’objets sur différentes plateformes. Cette application logicielle numérotée peut être déplacée vers différentes platfroms sans aucun changement de comportement. Le modèle d’usine abstrait conserve les classes concrètes utilisées sous une même interface.

Modèle Builder
Il permet de créer un groupe complexe d’objets en pièces au besoin via une interface unique. Lorsque l’utilisateur utilise le groupe d’objets, le groupe d’objets est structuré dans la direction requise. Les pièces inutilisées sont créées inutilement et ne consomment pas de ressources.

Le motif singleton
Dans une classe, un seul objet est créé pour être créé. Cet objet est accessible depuis n’importe où dans l’application. L’objet peut ne pas être créé avant d’être utilisé pour la première fois.

Modèles structurels
Il fournit des suggestions qui permettent la construction de structures logicielles plus larges en combinant des classes de structure et des objets. Les modèles de structure de classe et les modèles de structure d’objet sont divisés en deux.

Les structures de structure de classe étendent les constructions en utilisant l’héritage de classe ou les applications de composition. Les modèles de structure d’objet montrent comment combiner des objets pour gagner de nouvelles fonctions.

Modèle composite
Il permet aux objets d’être combinés ensemble dans une relation pièce-entière avec une structure arborescente, et ce composé peut être atteint à partir d’une seule interface. La structure composée peut s’étendre et se contracter avec le temps en ajoutant et en supprimant de nouveaux objets.

Façade (motif de façade)
Il permet d’utiliser une structure complexe dans une même interface.

Motif de décorateur
Il permet à un objet d’ajouter de nouvelles responsabilités sans changer l’objet. Il permet d’améliorer la fonctionnalité des objets sans sous-classification.

Modèle de pont
Il permet à la fois l’interface et l’implémentation concrète d’être séparées les unes des autres. La modification de l’interface n’affecte pas l’interface. Les deux peuvent être développés indépendamment.

Modèle de poids mouche
Au lieu de créer un grand nombre d’objets similaires, il permet la création d’une structure d’objet encombrée en créant des objets visuels à partir d’un exemple d’objet. Les variables d’état des objets visuels sont stockées par l’utilisateur, et non par l’objet lui-même.

Modèle d’adaptateur
Il est utilisé pour adapter les interfaces d’objets ou de classes de différentes sources.

Modèle de proxy
Il est possible d’imiter l’interface pour utiliser des objets compliqués, coûteux et difficiles à construire. Il permet de cacher à l’utilisateur l’orientation de l’objet physique de l’objet.

Les comportements
Les modèles comportementaux fournissent des suggestions sur la façon dont les responsabilités fonctionnelles peuvent être attribuées entre les objets et comment les méthodes de solution requises par le logiciel peuvent être utilisées objectivement. Les modèles comportementaux fournissent également des objets et des modèles de classes, ainsi que des modèles liés à la communication entre les objets. Les modèles comportementaux permettent au concepteur de se concentrer sur les méthodes de communication et de communication entre les objets.

Les modèles comportementaux sont également divisés en deux, tout comme ils le sont dans les modèles structurels: les modèles de comportement de classe et les modèles de comportement d’objet.

Les modèles de comportement de classe permettent de répartir le comportement entre les classes en utilisant l’héritage. Les modèles de comportement d’objet permettent d’obtenir un comportement par le biais d’un groupe d’objets qui ne peut pas facilement être atteint par un seul objet via la composition d’objet.

Motif de médiateur
Les objets connectés les uns aux autres peuvent être guidés à partir d’un seul point (c’est-à-dire par le viseur) sous le même toit. Les objets connectés au moteur de recherche communiquent les changements d’état au moteur de recherche. Le chercheur trouve des demandes d’objets liés à l’édition et à la commande requises par l’application. Les objets utilisateur de niveau supérieur ne se connectent qu’au Finder.

Modèle d’état
Il permet à un objet de changer son comportement en fonction de sa situation. Du point de vue de l’utilisateur, cela donne l’impression que vous modifiez la classe d’objets. Il permet d’ajouter et de supprimer de nouveaux comportements dans la direction requise par l’application. Les objets utilisateur ne sont pas affectés par de tels changements.

Modèle d’observateur
Il permet à un groupe d’objets, observateurs, d’être automatiquement informé des changements dans un objet observé. L’objet observé continue à fonctionner indépendamment de qui est suivi. Il est possible que de nouveaux observateurs participent ou partent à temps. De cette manière, l’application peut changer de comportement au fil du temps.

Modèle de méthode de modèle
Cela permet d’utiliser une procédure comme modèle de solution. Il permet à certaines étapes de traitement sur le dé d’être traitées par des sous-classes. Par conséquent, certaines étapes intermédiaires peuvent être modifiées sans changer le motif principal. Les utilisateurs ne sont pas conscients de ces changements.

Motif de commande
Il permet aux requêtes utilisateur (objectif) d’être transformées en objets et traitées. De cette manière, les souhaits de différents utilisateurs peuvent être convertis en enregistrements objectifs et conservés dans des files d’attente ou des enregistrements. Il est également possible d’inverser les transactions effectuées sur ce coffre-fort.

Chaîne de responsabilités (chaîne de responsabilité)
Un utilisateur (objectif) permet à la demande d’être évaluée par plusieurs objets à satisfaire. l’utilisateur transmet la demande via une interface unique. Les demandes sont traitées à leur tour par les objets connectés à la requête. La demande est transférée d’un objet à l’autre sur la chaîne jusqu’à ce qu’elle soit accueillie. Il est possible d’ajouter ou de supprimer de nouveaux objets dans la chaîne au fil du temps. L’utilisateur n’est pas affecté par l’interface de ces modifications.

Modèle d’interprète
Le pseudo-langage défini pour répondre aux exigences des applications complexes est un modèle d’interprète. Le pseudo-langage permet d’appliquer facilement les règles grammaticales en les définissant comme des classes. Puisque les règles de grammaire sont définies en tant que classes, elles peuvent être facilement modifiées et améliorées.

Yadigâr (modèle de souvenir)
Yadigâr est utilisé pour cacher les états des objets qui jouent des rôles importants dans le logiciel d’application et pour les rappeler ou les rappeler quand c’est nécessaire.

Motif d’itération
Il garantit que les objets situés sous un objet de masse (Aggragate Object) peuvent être atteints en séquence, quelle que soit la manière dont les objets sont représentés ou réalisés. Les objets représentés de cette manière sont accessibles via une interface unique.

Stratégie (stratégie pattery)
Sous la même interface, de nombreuses méthodes de résolution pouvant résoudre le même problème masquent la classe, ce qui permet de satisfaire les requêtes des objets utilisateur sans connaître la méthode utilisée. L’utilisateur est confronté à différentes formes de comportement lorsqu’il prétend travailler avec le même type d’objet.

Modèle de visiteur
Il permet d’ajouter de nouvelles opérations sur une structure composée. Le visiteur visite des objets individuels dans la structure composée, recueille les informations nécessaires, les traite et les présente à l’utilisateur.