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 .