Qu'est-ce qu'un anti-motif?
J'étudie des modèles et des anti-modèles. J'ai une idée claire des modèles, mais je n'ai pas d'anti-modèles. Les définitions du Web et de Wikipedia 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?
Anti-patterns certains modèles de développement logiciel sont considérés comme de mauvaises pratiques de programmation.
Par opposition aux modèles de conception qui sont des approches communes de problèmes communs formalisés et généralement considérés comme une bonne pratique de développement, les anti-modèles sont le contraire et sont indésirables.
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-motif dans la programmation orientée objet est un objet divin qui remplit de nombreuses fonctions qu'il serait préférable de séparer 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 everything. Dans la programmation orientée objet, il serait préférable d’avoir des responsabilités bien définies pour différents objets afin que le code soit moins couplé et plus facilement maintenable:
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 bonnes méthodes pour développer des logiciels avec les modèles couramment utilisés ( modèles de conception ), mais il existe également des méthodes de développement et de mise en œuvre de logiciels pouvant générer 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 ont un impact négatif sur la qualité de la conception". (Tiré de "Refactoring pour les odeurs de conception logicielle: gestion de la dette technique")
Il existe de nombreuses odeurs de conception classées sur la base de violations des principes de conception:
L'abstraction sent
(Abstraction manquante:} _ Cette odeur survient lorsque des groupes 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 se dégage lorsqu'une opération est transformée en classe.
Abstraction incomplète: Cette odeur survient lorsqu'une abstraction ne prend pas complètement en charge les méthodes complémentaires ou interdépendantes.
Abstraction aux 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 qui aurait donc pu être évitée) est introduite dans une conception logicielle.
Abstraction inutilisée: Cette odeur se dégage lorsqu'une abstraction est laissée inutilisée (non directement utilisée ou inaccessible).
Duplicate Abstraction: _ Cette odeur survient lorsque deux ou plusieurs abstractions ont un nom identique ou une implémentation identique, voire les deux.
L'encapsulation sent
Encapsulation déficiente: _ Cette odeur se produit lorsque l'accessibilité déclarée d'un ou de plusieurs membres d'une abstraction est plus permissive qu'il n'est réellement nécessaire.
(Leaky Encapsulation:}} _ Cette odeur survient lorsqu'une abstraction "expose" ou "fuit" des détails d'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 inexploitée: Cette odeur survient lorsque le code client utilise des vérifications de type explicites (à l'aide d'instructions chained if-else ou switch qui vérifient le type de l'objet) au lieu d'exploiter la variation dans les types déjà encapsulés dans une hiérarchie.
Modularisation des odeurs
Broken Modularization: _ Cette odeur survient 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.
Insuffisance de la modularisation: Cette odeur survient lorsqu'il existe une abstraction qui n'a pas été complètement décomposée et qu'une décomposition supplémentaire pourrait réduire sa taille, sa complexité d'implémentation ou les deux.
Modularisation cycliquement dépendante: Cette odeur se dégage lorsque deux ou plusieurs abstractions dépendent l'une de l'autre directement ou indirectement (créant un couplage étroit entre les abstractions).
Modularization Hub-like: _ 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 survient lorsqu'un segment de code utilise une logique conditionnelle (généralement associée à des «types marqués») pour gérer de manière explicite les variations de comportement dans lesquelles une hiérarchie aurait pu être créée et utilisée pour encapsuler ces variations.
(Hiérarchie non nécessaire:} _ Cette odeur survient lorsque toute la hiérarchie d'héritage est inutile, ce qui indique que l'héritage a été appliqué inutilement pour le contexte de conception particulier.
(Hiérarchie non activée:} _ Cette odeur survient lorsqu'il y a une duplication inutile entre les types d'une hiérarchie.
Wide Hierarchy: _ Cette odeur survient lorsqu'une hiérarchie d'héritage est «trop» trop large pour indiquer 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 de besoins imaginaires plutôt que d'exigences réelles).
Deep Hierarchy: _ Cette odeur survient lorsqu'une hiérarchie d'héritage est «excessivement» profonde.
(Hiérarchie rebelle) Cette odeur survient lorsqu'un sous-type rejette les méthodes fournies par son ou ses supertypes.
Broken Hierarchy: _ Cette odeur survient lorsqu'un supertype et son sous-type ne partagent pas, de manière conceptuelle, une relation «IS-A» entraînant une substituabilité impossible.
Multipath Hierarchy: _ Cette odeur survient lorsqu'un sous-type hérite directement ou indirectement d'un supertype, ce qui entraîne des chemins d'héritage inutiles dans la hiérarchie.
(Hiérarchie cyclique:} _ Cette odeur survient lorsqu'un super-type 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 "Refactorisation des odeurs de conception de logiciel: gestion de la dette technique ". Quelques ressources plus pertinentes pourraient être trouvées ici .
Un motif est une idée de la façon de résoudre un problème de classe. Un anti-modèle est une idée de la façon de ne pas le résoudre car la mettre en œuvre entraînerait une mauvaise conception.
Un exemple: un "motif" consisterait à utiliser une fonction pour la réutilisation du code, un "anti-motif" consisterait à utiliser un copier-coller pour les mêmes. Les deux résolvent le même problème, mais l'utilisation d'une fonction conduit généralement à un code plus lisible et maintenable que le copier-coller.
Un anti-modèle est un moyen de ne pas résoudre un problème. Mais il y a plus que cela: c'est aussi un moyen fréquemment utilisé pour tenter 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 anti-motif est une forme littéraire qui décrit une solution courante à un problème qui génère des conséquences nettement négatives".
Ainsi, s’il s’agit d’une mauvaise pratique de programmation mais pas courante - limitée à une application, une société ou un programmeur, elle ne correspond pas à la partie "Pattern" de la définition de AntiPattern.
Une façon courante de faire des dégâts. Comme la classe dieu/cuisines (fait tout), par exemple.
Un anti-motif est le complément d'un motif design. Un anti-motif est une solution modèle que vous ne devriez pas utiliser dans certaines situations.
Tout comme avec un motif design, un anti-motif est également un modèle et une manière répétable de résoudre un problème donné, mais de manière non optimale et inefficace.
Fait intéressant, une manière donnée de résoudre un problème peut être à la fois un motif et un anti-motif. Singleton en est le principal exemple. Il apparaîtra dans les deux séries de littérature.
Aujourd'hui, les chercheurs et les praticiens en génie logiciel utilisent souvent les termes «anti-pattern» et «odor» de manière interchangeable. Cependant, ils ne sont pas identiques sur le plan conceptuel. L'entrée anti-modèle de Wikipedia 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 communément utilisé qui, malgré , Apparaît initialement comme une réponse appropriée et efficace à un problème , A généralement plus de conséquences néfastes que de résultats bénéfiques."
Il indique clairement qu'un anti-modèle 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 entraîne plus de passifs que d'avantages. D'autre part, une odeur est simplement une mauvaise pratique qui affecte négativement la qualité d'un logiciel. Par exemple, Singleton est un anti-modèle et la classe divine (ou Modularisation insuffisante) est une odeur de design.
Les anti-modèles sont des méthodes courantes utilisées par les gens pour programmer de manière erronée, ou du moins de manière moins satisfaisante.
Tout modèle de conception faisant plus de mal que de bien à un environnement de développement logiciel donné serait considéré comme anti-modèle.
Certains anti-modèles sont évidents mais d'autres non. Par exemple, Singleton, même si beaucoup le considèrent comme un bon vieux modèle mais d’autres non.
Vous pouvez vérifier la question Quel est le problème des 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.