Modèles de conception

1.1 Introduction aux modèles

Comme mentionné précédemment, un programmeur commence à travailler sur un programme en concevant son modèle : en compilant une liste d'entités sur lesquelles le programme fonctionnera. Et plus il y a d'entités dans le programme, plus le programme est complexe.

Par conséquent, afin de réduire la complexité du programme, ils essaient de standardiser les interactions des objets. Et c'est là que les modèles de conception ou les modèles de conception aident beaucoup le programmeur . Du modèle de conception anglais .

Important! En russe, le mot design signifie généralement design graphique, en anglais ce n'est pas le cas. Le mot anglais design a une signification plus proche du mot « design » et/ou « device ». Par exemple, la conception d'un moteur n'est pas son apparence, mais sa structure interne.

Par conséquent, un design pattern est exactement un design pattern/pattern. Je vous recommande d'arrêter complètement d'utiliser le mot design dans le sens d'« apparence ». Vous êtes le futur ingénieur logiciel, et pour vous le design est exactement le design.

Quel est donc ce patron de conception ? Tout d'abord, un modèle de conception est une solution standard à un problème standard . Une bonne solution efficace et éprouvée.

Disons qu'on vous a demandé de concevoir un vélo, vous pouvez en faire deux roues, trois ou même cinq. Donc d'ailleurs, à l'aube du design, ça l'était. Mais l'approche éprouvée est à deux roues. Mais l'approche évidente actuelle est passée par la douleur et les erreurs :

En règle générale, un modèle n'est pas une solution complète qui peut être directement convertie en code, c'est juste un exemple d'une bonne solution à un problème qui peut être utilisé dans diverses situations.

Les modèles orientés objet montrent les relations et les interactions entre les classes ou les objets , sans spécifier les classes finales ou les objets d'application qui seront utilisés.

1.2 Histoire des patrons de conception

Dans les années 70, les programmeurs étaient confrontés à la nécessité de développer de grands programmes sur lesquels devaient travailler des équipes de développement entières. Diverses méthodes d'organisation du travail ont été essayées, mais l'industrie de la construction a le plus influencé le développement.

Pour organiser le travail d'un grand groupe de personnes, des pratiques et des approches de l'industrie de la construction ont été utilisées. Soit dit en passant, c'est à partir de là que des termes tels que l'assemblage (construction), le développeur de logiciels (constructeur) et le concept d'architecture sont entrés dans la programmation.

Et comme vous pouvez le deviner, l'idée du modèle de conception a également été tirée de l'industrie de la construction. Le concept de motifs a été décrit pour la première fois par Christopher Alexander dans The Pattern Language. Villes. Bâtiment. Construction". Dans ce livre, un langage spécial, les motifs, a été utilisé pour décrire les processus de conception de la ville.

Les modèles de construction décrivaient des décisions typiques éprouvées par le temps : la hauteur des fenêtres, le nombre d'étages dans le bâtiment, la superficie du microdistrict à allouer aux arbres et aux pelouses.

Il n'est donc pas surprenant qu'en 1994 le livre « Techniques de conception orientée objet. Design Patterns », qui comprend 23 modèles qui résolvent divers problèmes de conception orientée objet.

Le livre a été écrit par 4 auteurs : Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Le titre du livre était trop long pour qu'on s'en souvienne. Par conséquent, bientôt tout le monde a commencé à l'appeler "livre par la bande de quatre", c'est-à-dire "un livre d'une bande de quatre" , puis même "livre GoF".

Et depuis, d'autres design patterns ont été découverts. L'approche par "modèles" est devenue populaire dans tous les domaines de la programmation, vous pouvez donc désormais trouver toutes sortes de modèles en dehors de la conception d'objets.

Important! Les modèles ne sont pas des solutions super originales, mais au contraire des solutions typiques fréquemment rencontrées au même problème. Bonnes solutions éprouvées.

1.3 Liste des modèles

De nombreux programmeurs n'ont pas appris un seul schéma de toute leur vie, ce qui ne les empêche cependant pas de les utiliser. Comme nous l'avons dit précédemment, les modèles sont de bonnes solutions éprouvées, et si le programmeur n'est pas un imbécile, alors avec l'expérience, il trouve lui-même de telles solutions.

Mais pourquoi, à travers des dizaines d'essais et d'erreurs, arriver à des solutions optimales alors qu'il y a des gens qui sont déjà passés par là et qui ont écrit des livres avec la quintessence de leur expérience et de leur sagesse de vie ?

Vous pouvez enfoncer un clou avec une clé, mais pourquoi ? Vous pouvez même utiliser une perceuse si vous essayez fort. Mais une bonne possession consciente de l'instrument est précisément ce qui distingue un professionnel d'un amateur. Et le professionnel sait que la principale caractéristique de la perceuse n'est pas du tout là-dedans. Alors, pourquoi avez-vous besoin de connaître les modèles ?

• Solutions éprouvées. Vous passez moins de temps à utiliser des solutions prêtes à l'emploi au lieu de réinventer la roue. Certaines décisions auxquelles vous pourriez penser vous-même, mais beaucoup peuvent être une découverte pour vous.
• Normalisation des codes. Vous faites moins d'erreurs de calcul lors de la conception, en utilisant des solutions unifiées typiques, car tous les problèmes cachés qu'elles contiennent ont été trouvés depuis longtemps.
• Dictionnaire général de programmation. Vous prononcez le nom du modèle au lieu de passer une heure à expliquer aux autres programmeurs quel design sympa vous avez proposé et quelles classes sont nécessaires pour cela.

Quels sont les motifs ?

Les modèles diffèrent par le niveau de complexité, de détail et de couverture du système en cours de conception. Faisant une analogie avec la construction, vous pouvez augmenter la sécurité d'une intersection en installant un feu de circulation, ou vous pouvez remplacer l'intersection par un échangeur de voitures complet avec des passages souterrains.

Les modèles les plus bas et les plus simples sont les idiomes. Ils ne sont pas universels, puisqu'ils ne sont applicables que dans le cadre d'un langage de programmation.

Les modèles architecturaux les plus polyvalents peuvent être implémentés dans presque toutes les langues. Ils sont nécessaires pour concevoir l'ensemble du programme, et non ses éléments individuels.

Mais l'essentiel est que les modèles diffèrent dans leur objectif. Les modèles avec lesquels nous allons nous familiariser peuvent être divisés en trois groupes principaux :

• Les modèles de création prennent en charge la création flexible d'objets sans introduire de dépendances inutiles dans le programme.
• Les modèles structurels montrent différentes manières de construire des relations entre les objets.
• Les modèles de comportement veillent à une communication efficace entre les objets.

1.4 Introduction à UML

Commençons par examiner les mêmes 23 modèles qui ont été décrits dans le livre Gang of Four. Les modèles eux-mêmes et leurs noms sont des choses familières, même pour un programmeur novice. Je vais vous les présenter, mais je vous recommande fortement de lire ce même livre sur les modèles.

Les modèles de conception ne sont pas liés à un langage de programmation spécifique, c'est pourquoi UML est généralement utilisé pour les décrire. Il était très populaire il y a 20 ans, mais même maintenant, il est parfois utilisé. Et soit dit en passant, la description des modèles n'est que l'endroit où l'utilisation d'UML est la norme.

Avec UML, vous pouvez décrire des relations entre différentes entités. Dans notre cas, ce sont des objets et des classes.

Les relations entre classes sont décrites par quatre types de flèches :

En fait, tout est très simple ici. La dernière flèche signifie en fait qu'une classe est héritée d'une autre classe. Et les première et deuxième flèches indiquent qu'un objet stocke un lien vers le deuxième objet. Et c'est tout.

Si le losange du lien est noir, alors le lien est faible : les objets peuvent exister les uns sans les autres. Si le losange est blanc, les objets sont fortement liés, comme une classe HttpRequestet sa classe enfant HttpRequest.Builder.

1.5 Liste des modèles

Les types de motifs seront indiqués par différentes couleurs et lettres :

B- comportemental (comportemental);

C- générer (créationnel);

S- structurel (structurel).

Et enfin, une liste de 23 patrons de conception :