> Les patrons de conception sont des **solutions classiques** à des **problèmes récurrents** de la **conception de logiciels**. Ce sont des sortes de plans ou de schémas que l’on peut **personnaliser** afin de résoudre un problème récurrent dans notre code. https://refactoring.guru/fr/design-patterns/what-is-pattern Les patrons de conception - sont une boîte à outils de **solutions fiables et éprouvées** - définissent un **langage commun** qui peut être utilisés pour communiquer avec nos pairs et permettent de réduire la [[Glossaire général#Charge cognitive|charge cognitive]] en identifiant des concepts parfois complexes en peu de mots. > [!danger] Attention à la patternite ! > Il peut être tentant de résoudre tous les problèmes à l'aide de patrons de conception. > Mais rappelons-nous qu'ils s'appuient parfois sur des [[Glossaire général#Abstraction|abstractions]] qui peuvent parfois ajouter des **indirections** et augmenter la **compléxité programmatique** ou encore **l'empreinte mémoire** d'un code ## Patterns et frameworks Lorsque vous utilisez certains Framework de programmation comme JavaFx ou Spring ou autre, vous utilisez certainement sans le savoir beaucoup de design patterns. ## Antipatterns Les "anti-patterns" sont des solutions généralement admises comme nuisibles **dans leur contexte** et dans leur **époque**. Cela peut être - des design patterns qui étaient utiles hier, et aujourd’hui sont problématiques. - des solutions naïves qui semble évidentes au premier abord mais qui cachent des écueils quand on creuse un peu plus loin. Certains d’entre eux sont même devenu idiomatiques et très répondu et font partie des standards du langage. Je pense par exemple à la convention Java Bean <!-- , qui consiste à entre guillemets encapsuler des données dans une classe en fournissant automatiquement guetteur et c’est tard pour accéder et modifier les propriétés de l’objet. Ce qui de facto casse son encapsulation.Autre fois cette convention était pratique pour faire fonctionner certains frais moi qui ai librairie qui s’appuyer sur cette convention. Aujourd’hui c’est moins le cas car les pratiques et utilisation de ses Frameworks ne le nécessite plus forcément. Exemple pour les jeunes Tavin pour l’injection de dépendance traditionnellement en utiliser la réflexion ou 17 heures pour injecter et les dépendances, aujourd’hui on a plutôt tendance à injecter les dépendances via les paramètres de constructeurs. Autre exemple de ce que je considère comme un anti paterne des Antilles paterne de nommage, en utilisant des suffixes ou des préfixes qui répète l’intention qui est déjà présente dans le code. Exemple su fixer les exceptions avec exception ne nous aide pas beaucoup puisque c’est classe Éric déjà deux exceptions août sur la belle et, pire que cela cache souvent un mauvais dommage. Autre exemple, j’ai fixé les interfaces avec qui ou interfaces, ou suffixé les classes implémentation par un Plans,. Cela cache en général un manque d’inspiration dans le nommage et ne reflète pas la raison de l’implémentation. On préfère alors préfixé une implémentation avec ce qui la rend spécifique. Par exemple il memory adresse sise, plutôt que adresse repos Hitori un Plans. --> https://web.archive.org/web/20220409155838/https://sourcemaking.com/antipatterns/software-development-antipatterns https://web.archive.org/web/20220409155842/https://sourcemaking.com/antipatterns/software-architecture-antipatterns https://web.archive.org/web/20220528035708/https://sourcemaking.com/antipatterns/software-project-management-antipatterns ## Refactoring Les refactoring où est usinage sont des gestes de programmation consistant à modifier la structure d’un code sans en modifier le comportement visible Un certain nombre d’entre eux sont disponibles de façon automatique dans certains de nos outils Exemple : A la ligne A la ligne extraire une méthode, extraire une variable renommée une méthode renommée une variable renommée une classe déplacer une méthode d’une classe à l’autre À l’intérieur d’un projet c’est factoring sont considérés comme des refactoring peu risqué. Ce sont des petits gestes qui combinés peuvent permettre de modifier la conception d’un logiciel pour le rendre plus maintenable est où réutilisable ## À suivre [[Introduction à JavaFx]]