Qu’est-ce qu’un anti-pattern?

J’étudie les patrons et les anti-patrons. J’ai une idée claire des motifs, mais je ne reçois pas d’anti-modèles. Les définitions du Web et de Wikipedia me déroutent beaucoup.

Quelqu’un peut-il m’expliquer en termes simples ce qu’est un anti-modèle? Quel est le but? Que font-ils? Est-ce une mauvaise chose ou une bonne chose?

Les anti-patterns sont certains modèles de développement logiciel qui sont considérés comme de mauvaises pratiques de programmation.

Contrairement aux modèles de conception qui sont des approches communes à des problèmes communs qui ont été formalisés et sont généralement considérés comme une bonne pratique de développement, les anti-modèles sont opposés et indésirables.

Par exemple, en programmation orientée object, l’idée est de séparer le logiciel en petits morceaux appelés objects. Un anti-pattern dans la programmation orientée object est un object de Dieu qui effectue beaucoup de fonctions qui seraient mieux séparées en différents objects.

Par exemple:

class GodObject { function PerformInitialization() {} function ReadFromFile() {} function WriteToFile() {} function DisplayToScreen() {} function PerformCalculation() {} function ValidateInput() {} // and so on... // } 

L’exemple ci-dessus a un object qui fait tout . Dans la programmation orientée object, il serait préférable d’avoir des responsabilités bien définies pour les différents objects afin de garder le code moins couplé et, en fin de compte, plus facile à maintenir:

 class FileInputOutput { function ReadFromFile() {} function WriteToFile() {} } class UserInputOutput { function DisplayToScreen() {} function ValidateInput() {} } class Logic { function PerformInitialization() {} function PerformCalculation() {} } 

L’essentiel est qu’il existe de bons moyens de développer des logiciels avec des modèles couramment utilisés (modèles de conception ), mais il existe également des moyens permettant de développer et d’implémenter des logiciels pouvant entraîner des problèmes. Les modèles considérés comme de mauvaises pratiques de développement logiciel sont des anti-modèles.

Chaque fois que j’entends parler d’Anti-Patterns, je me souviens d’un autre terme à savoir. Odeur de design

“Les odeurs de conception sont certaines structures de la conception qui indiquent une violation des principes de conception fondamentaux et ont un impact négatif sur la qualité de la conception” (extrait de “Refactoring pour les logiciels: gestion de la dette technique”)

Il existe de nombreuses odeurs de conception classées en fonction des principes de conception violés:

L’abstraction sent

Abstraction manquante: cette odeur se produit lorsque des groupes de données ou des chaînes codées sont utilisées au lieu de créer une classe ou une interface.

Abstraction impérative: cette odeur se produit lorsqu’une opération est transformée en une classe.

Abstraction incomplète: cette odeur apparaît lorsqu’une abstraction ne supporte pas complètement les méthodes complémentaires ou interdépendantes.

Abstraction à facettes multiples: cette odeur se produit lorsqu’une abstraction a plus d’une responsabilité qui lui est assignée.

Abstraction inutile: cette odeur se produit lorsqu’une abstraction qui n’est pas réellement nécessaire (et qui aurait donc pu être évitée) est introduite dans une conception logicielle.

Abstraction inutilisée: cette odeur se produit lorsqu’une abstraction est laissée inutilisée (non directement utilisée ou inaccessible).

Abstraction en double: cette odeur se produit lorsque deux abstractions ou plus ont des noms identiques ou une implémentation identique ou les deux.

Odeurs d’encapsulation

Encapsulation insuffisante: cette odeur se produit lorsque l’accessibilité déclarée d’un ou plusieurs membres d’une abstraction est plus permissive que ce qui est réellement requirejs.

Leaky Encapsulation: Cette odeur se produit lorsqu’une abstraction «expose» ou «fuit» les détails de l’implémentation via son interface publique.

Encapsulation manquante: cette odeur se produit lorsque les variantes d’implémentation ne sont pas encapsulées dans une abstraction ou une hiérarchie.

Encapsulation non exploitée: cette odeur se produit lorsque le code client utilise des vérifications de type explicites (à l’aide d’instructions chaînées if-else ou switch qui vérifient le type de l’object) au lieu d’exploiter la variation des types déjà encapsulés dans une hiérarchie.

La modularisation des odeurs

Modularisation brisée: cette odeur se produit lorsque des données et / ou des méthodes qui auraient dû être localisées en une seule abstraction sont séparées et réparties sur plusieurs abstractions.

Modularisation insuffisante: cette odeur se produit lorsqu’une abstraction existe qui n’a pas été complètement décomposée et qu’une décomposition ultérieure pourrait réduire sa taille, sa complexité d’implémentation ou les deux.

Modularisation dépendante du cycle: cette odeur se produit lorsque deux abstractions ou plus dépendent directement ou indirectement l’une de l’autre (créant un couplage étroit entre les abstractions).

Modularisation Hub-Like: Cette odeur se produit quand une abstraction a des dépendances (à la fois entrantes et sortantes) avec un grand nombre d’autres abstractions.

La hiérarchie sent

Hiérarchie manquante: cette odeur survient lorsqu’un segment de code utilise une logique conditionnelle (généralement associée à des «types balisés») pour gérer explicitement les variations de comportement lorsqu’une hiérarchie aurait pu être créée et utilisée pour encapsuler ces variations.

Hiérarchie inutile: cette odeur survient lorsque toute la hiérarchie d’inheritance est inutile, ce qui indique que l’inheritance a été appliqué inutilement pour le contexte de conception particulier.

Hiérarchie non implémentée: cette odeur se produit lorsqu’il y a une duplication inutile entre les types dans une hiérarchie.

Wide Hierarchy: Cette odeur se produit lorsqu’une hiérarchie d’inheritance est trop large pour indiquer que des types intermédiaires peuvent être manquants.

Hiérarchie spéculative: cette odeur se produit lorsqu’un ou plusieurs types d’une hiérarchie sont fournis de manière spéculative (c’est-à-dire basés sur des besoins imaginés plutôt que sur des besoins réels).

Hiérarchie profonde: cette odeur se produit lorsqu’une hiérarchie d’inheritance est «excessivement» profonde.

Hiérarchie rebelle: cette odeur apparaît lorsqu’un sous-type rejette les méthodes fournies par ses supertypes.

Hiérarchie brisée: cette odeur se produit lorsqu’un supertype et son sous-type ne partagent pas conceptuellement une relation «ISA» entraînant une substituabilité rompue.

Hiérarchie Multipath: Cette odeur se produit lorsqu’un sous-type hérite à la fois directement et indirectement d’un supertype, entraînant des chemins d’inheritance inutiles dans la hiérarchie.

Hiérarchie cyclique: cette odeur se produit lorsqu’un supertype d’une hiérarchie dépend de l’un de ses sous-types.


La définition et la classification ci-dessus sont décrites dans “Refactoring pour les odeurs de conception de logiciels: Gestion de la dette technique “. Des ressources plus pertinentes pourraient être trouvées ici .

Un modèle est une idée de la façon de résoudre un problème d’une classe. Un anti-pattern est une idée de comment ne pas le résoudre car la mise en œuvre de cette idée entraînerait une mauvaise conception.

Un exemple: un “pattern” serait d’utiliser une fonction de réutilisation de code, un “anti-pattern” serait d’utiliser un copy-paste pour le même. Les deux résolvent le même problème, mais l’utilisation d’une fonction conduit généralement à un code plus lisible et plus maintenable que le copier-coller.

Un anti-pattern est un moyen de ne pas résoudre un problème. Mais il y a plus à faire: c’est aussi une façon de voir souvent dans les tentatives de résoudre le problème.

Si vous souhaitez vraiment étudier AntiPatterns, procurez-vous le livre AntiPatterns (ISBN-13: 978-0471197133).

Dans ce document, ils définissent “Un AntiPattern est une forme littéraire qui décrit une solution courante à un problème qui génère des conséquences décidément négatives”.

Donc, si c’est une mauvaise pratique de programmation mais pas une pratique courante – limitée à une application, une entreprise ou un programmeur, elle ne répond pas à la partie “Pattern” de la définition d’AntiPattern.

Une façon courante de faire un gâchis. Comme la classe dieu / kitchensink (fait tout), par exemple.

Un anti-pattern est le complément d’un motif de conception . Un anti-pattern est une solution modèle que vous ne devez pas utiliser dans certaines situations.

Tout comme avec un motif de conception , un anti-pattern est également un modèle et un moyen reproductible de résoudre un problème donné, mais de manière non optimale et inefficace.

Il est intéressant de noter qu’une façon de résoudre un problème peut être à la fois un modèle et un anti-modèle. Singleton en est le meilleur exemple. Il apparaîtra dans les deux ensembles de littérature.

Aujourd’hui, les chercheurs en génie logiciel et les praticiens utilisent souvent les termes «anti-pattern» et «odor» de manière interchangeable. Cependant, ils sont conceptuellement différents. L’entrée Wikipedia de l’anti-modèle indique qu’un anti-modèle est différent d’une mauvaise pratique ou d’une mauvaise idée par au moins deux facteurs. Un anti-pattern est

“Un processus, une structure ou un modèle d’action communément utilisé, qui, au départ, semblait constituer une réponse appropriée et efficace à un problème, a généralement plus de conséquences négatives que de résultats bénéfiques.”

Cela indique clairement qu’un anti-pattern est choisi dans la conviction qu’il s’agit d’une bonne solution (en tant que modèle) au problème présenté; Cependant, cela engendre plus de passif que d’avantages. D’un autre côté, une odeur est simplement une mauvaise pratique qui affecte négativement la qualité d’un système logiciel. Par exemple, Singleton est un anti-pattern et la classe God (ou Insufficient Modularization) est une odeur de conception.

Les anti-modèles sont des moyens courants que les gens ont tendance à programmer de manière incorrecte, ou du moins pas dans le bon sens.

Tout modèle de conception qui fait plus de mal que de bien à un environnement de développement logiciel donné serait considéré comme un anti-modèle.

Certains anti-patterns sont évidents mais certains ne le sont pas. Par exemple Singleton, même si beaucoup le considèrent comme un bon vieux modèle de conception, mais d’autres non.

Vous pouvez vérifier la question Qu’est-ce qui est si mauvais à propos des singletons? pour mieux comprendre les différentes opinions à ce sujet.