Qu'est-ce qu'un anti-motif?

J'étudie les patrons et les anti-patrons. J'ai une idée claire des motifs, mais je n'ai pas d'anti-motifs. Les définitions du Web et de Wikipédia me confondent 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 ou une bonne chose?

Les anti-modèles 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 le contraire et ne sont pas souhaitables.

Par exemple, dans la programmation orientée objet, l'idée est de séparer le logiciel en petits morceaux appelés objets. Un anti-modèle dans la programmation orientée objet est un objet Dieu qui remplit de nombreuses fonctions qui seraient mieux séparées en différents objets.

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 objet qui fait tout . Dans la programmation orientée objet, il serait préférable d'avoir des responsabilités bien définies pour différents objets pour garder le code moins couplé et finalement plus maintenable:

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

L'essentiel, c'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 de développer et de mettre en œuvre des logiciels qui peuvent entraîner des problèmes. Les modèles considérés comme de mauvaises pratiques de développement de logiciels sont des anti-modèles.

Chaque fois que j'entends parler d'Anti-patterns, je me souviens d'un autre terme, à savoir. Odeur de conception.

«Les odeurs de conception sont certaines structures de la conception qui indiquent une violation des principes de conception fondamentaux et un impact négatif sur la qualité de la conception». (Extrait de «Refactoring for Software Design Smells: Managing Technical dette»)

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

L'abstraction sent

Abstraction manquante: cette odeur apparaît lorsque des blocs de données ou des chaînes codées sont utilisés au lieu de créer une classe ou une interface.

Abstraction impérative: cette odeur apparaît lorsqu'une opération est transformée en classe.

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

Abstraction à multiples facettes: cette odeur survient 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 aurait donc pu être évitée) est introduite dans une conception logicielle.

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

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

L'encapsulation sent

Encapsulation déficiente: cette odeur se produit lorsque l'accessibilité déclarée d'un ou plusieurs membres d'une abstraction est plus permissive qu'elle n'est réellement requise.

Leaky Encapsulation: cette odeur survient lorsqu'une abstraction «expose» ou «fuit» les détails de mise en œuvre via son interface publique.

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

Encapsulation inexploitée: cette odeur apparaît lorsque le code client utilise des vérifications de type explicites (en utilisant des instructions if-else ou switch chaînées qui vérifient le type de l'objet) au lieu d'exploiter la variation des types déjà encapsulés dans une hiérarchie.

La modularisation sent

Modularisation brisée: cette odeur apparaît lorsque des données et / ou des méthodes qui auraient idéalement dû être localisées dans une seule abstraction sont séparées et réparties sur plusieurs abstractions.

Modularisation insuffisante: cette odeur apparaît lorsqu'une abstraction existe qui n'a pas été complètement décomposée, et qu'une décomposition supplémentaire pourrait réduire sa taille, sa complexité de mise en œuvre, ou les deux.

Modularisation cycliquement dépendante: cette odeur apparaît lorsque deux ou plusieurs abstractions dépendent directement ou indirectement l'une de l'autre (créant un couplage étroit entre les abstractions).

Modularisation de type concentrateur: cette odeur survient lorsqu'une abstraction a des dépendances (entrantes et sortantes) avec un grand nombre d'autres abstractions.

La hiérarchie sent

Hiérarchie manquante: cette odeur apparaît lorsqu'un segment de code utilise une logique conditionnelle (généralement en conjonction avec des «types balisés») pour gérer explicitement la variation de comportement là où une hiérarchie aurait pu être créée et utilisée pour encapsuler ces variations.

Hiérarchie inutile: cette odeur apparaît lorsque toute la hiérarchie d'héritage n'est pas nécessaire, ce qui indique que l'héritage a été appliqué inutilement pour le contexte de conception particulier.

Hiérarchie non factorisée: cette odeur apparaît lorsqu'il y a duplication inutile entre les types d'une hiérarchie.

Hiérarchie large: cette odeur apparaît lorsqu'une hiérarchie d'héritage est «trop» large, indiquant que des types intermédiaires peuvent être manquants.

Hiérarchie spéculative: cette odeur survient lorsqu'un ou plusieurs types d'une hiérarchie sont fournis de manière spéculative (c'est-à-dire en fonction des besoins imaginés plutôt que des exigences réelles).

Hiérarchie profonde: cette odeur apparaît lorsqu'une hiérarchie d'héritage est «excessivement» profonde.

Hiérarchie rebelle: cette odeur apparaît lorsqu'un sous-type rejette les méthodes fournies par son ou ses supertype (s).

Hiérarchie brisée: cette odeur apparaît lorsqu'un supertype et son sous-type ne partagent pas conceptuellement une relation «IS-A», ce qui entraîne une substituabilité brisée.

Hiérarchie à trajets multiples: cette odeur survient lorsqu'un sous-type hérite à la fois directement et indirectement d'un supertype conduisant à des chemins d'héritage inutiles dans la hiérarchie.

Hiérarchie cyclique: cette odeur apparaît lorsqu'un supertype dans une hiérarchie dépend de l'un de ses sous-types.

La définition et la classification ci-dessus sont décrites dans «Refactorisation des odeurs de conception de logiciels: gestion de la dette technique ». Des ressources plus pertinentes peuvent ê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-modèle est une idée de la façon de ne pas le résoudre, car la mise en œuvre de cette idée entraînerait une mauvaise conception.

Un exemple: un "modèle" serait d'utiliser une fonction pour la réutilisation de code, un "anti-modèle" serait d'utiliser le copier-coller 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 facile à gérer que le copier-coller.

Un anti-modèle est un moyen de ne pas résoudre un problème. Mais il y a plus: c'est aussi un moyen que l'on peut fréquemment voir 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 courante - limitée à une application, une entreprise ou un programmeur, elle ne correspond pas à la partie "Pattern" de la définition d'AntiPattern.

Une façon courante de gâcher. Comme la classe god / kitchensink (fait tout), par exemple.

Fait intéressant, une façon donnée 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 séries de littérature.

Un anti-motif est le complément d'un motif design . Un anti-modèle est une solution de modèle que vous ne devez pas utiliser dans une certaine situation.

Tout comme avec un modèle de conception , un anti-modèle est également un modèle et une manière répétable de résoudre un certain problème, mais de manière non optimale et inefficace.

Aujourd'hui, les chercheurs et les praticiens en génie logiciel utilisent souvent les termes «anti-modèle» et «odeur» de manière interchangeable. Cependant, ils ne sont pas conceptuellement les mêmes. L'entrée de Wikipédia sur 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-motif est

«Un processus, une structure ou un schéma d'action couramment utilisés qui, bien qu'ils semblent initialement être une réponse appropriée et efficace à un problème, ont généralement plus de conséquences néfastes que des résultats bénéfiques.»

Il indique clairement qu'un anti-modèle est choisi dans la conviction qu'il est une bonne solution (en tant que modèle) au problème présenté; cependant, cela entraîne plus de responsabilités 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-modèle et la classe God (ou Modularisation insuffisante) est une odeur de conception.

Les anti-schémas sont des façons courantes pour les gens de programmer de la mauvaise façon, ou du moins de la mauvaise façon.

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

Certains anti-schémas 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 il y en a d'autres qui ne le font pas.

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

Comme dans Algorithm, vous pouvez obtenir la solution en utilisant la force brute, mais vous devez payer beaucoup si la situation devient complexe.