Qu'est ce qu'un anti-modèle?
j'étudie les motifs et les anti-motifs. J'ai une idée claire sur les motifs, mais je n'ai pas d'anti-motifs. Les définitions du web et de Wikipédia me déconcertent beaucoup.
quelqu'un Peut-il m'expliquer en termes simples ce qu'un anti-modèle? Quel est le but? Que font-ils? Est-ce une mauvaise chose ou une bonne chose?
12 réponses
Anti-patterns sont certains patterns dans le développement de logiciels qui sont considérés comme de mauvaises pratiques de programmation.
par opposition à design patterns 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, anti-patterns sont le contraire et sont indésirables.
Par exemple, dans la programmation orientée objet, l'idée est pour séparer le logiciel en petits morceaux appelés objets. Un anti-pattern dans la programmation orientée objet est un God object qui exécute un grand nombre de 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 . En 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() {}
}
au bout du compte, il y a de bonnes façons de développer des logiciels avec des modèles courants ( modèles de conception ), mais il y a aussi des façons de développer et de mettre en œuvre des logiciels qui peuvent causer des problèmes. Les modèles qui sont considérés comme de mauvaises pratiques de développement de logiciels sont anti-modèles.
chaque fois que j'entends parler D'anti-patterns, je me souviens d'un autre terme: La conception de l'odorat.
"le Design des odeurs de certaines structures dans la conception qui indiquent la violation de principes de conception fondamentaux et un impact négatif sur la qualité de la conception". (À partir de "Refactoring pour la Conception de Logiciels Odeurs: la Gestion de la dette technique")
il y a de nombreuses odeurs de design classées sur la base de la violation des principes de design:
Abstraction sent
Abstraction manquante: cette odeur apparaît lorsque des amas de données ou des chaînes encodé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 supporte pas méthodes complémentaires ou interdépendantes complètement.
Abstraction à multiples facettes: cette odeur apparaît lorsqu'une abstraction a plus d'une responsabilité qui lui est assignée.
Abstraction inutile: cette odeur se produit quand une abstraction qui n'est pas réellement nécessaire (et donc aurait pu être évitée) est introduite dans un design logiciel.
non utilisé Abstraction: cette odeur se produit lorsqu'une abstraction est laissée inutilisée (soit non utilisée directement, soit non accessible).
Duplicate Abstraction: cette odeur se produit lorsque deux ou plusieurs abstractions ont des noms identiques ou une implémentation identique ou les deux.
odeurs D'Encapsulation
encapsulation déficiente: cette odeur se produit lorsque le produit déclaré l'accessibilité d'un ou de plusieurs membres d'une abstraction est plus permissive que réellement nécessaire.
Encapsulation de fuite: cette odeur se produit lorsqu'une abstraction "expose" ou "fuit" des détails de mise en œuvre à travers son interface publique.
encapsulation manquante: cette odeur se produit lorsque les variations de mise en œuvre ne sont pas encapsulées dans une abstraction ou une hiérarchie.
encapsulation inexploitée: cette odeur se produit lorsque le code client utilise des contrôles de type explicites (en utilisant des instructions enchaînées if-else ou switch qui vérifient le type de l'objet) au lieu d'exploiter la variation des types déjà encapsulés dans une hiérarchie.
odeurs de modularisation
modularisation brisée: cette odeur apparaît lorsque des données et / ou des méthodes qui idéalement devraient avoir été localisés dans une abstraction unique sont séparés et répartis à travers de multiples abstractions.
modularisation insuffisante: cette odeur apparaît lorsqu'il existe une abstraction qui n'a pas été complètement décomposée, et une décomposition ultérieure pourrait réduire sa taille, la complexité de sa mise en œuvre, ou les deux.
modularisation dépendante du cycle: cette odeur se produit lorsque deux ou plus les abstractions dépendent l'une de l'autre directement ou indirectement (créant un couplage étroit entre les abstractions).
modularisation en Hub: cette odeur apparaît lorsqu'une abstraction a des dépendances (entrantes et sortantes) avec un grand nombre d'autres abstractions.
la hiérarchie sent
Manque de Hiérarchie: Cette odeur se pose lorsqu'un code segment utilise la logique conditionnelle (généralement en conjonction avec les "types marqués") pour gérer explicitement la variation dans le comportement où une hiérarchie aurait pu être créée et utilisée pour encapsuler ces variations.
hiérarchie inutile: cette odeur se produit lorsque toute la hiérarchie de l'héritage est inutile, ce qui indique que l'héritage a été appliqué inutilement pour le contexte particulier de la conception.
Non Affacturé Hiérarchie: cette odeur se produit lorsqu'il y a une duplication inutile entre les types dans une hiérarchie.
à l'Échelle de la Hiérarchie: Cette odeur se pose lorsqu'une hiérarchie d'héritage est "trop" de large, indiquant que des types intermédiaires peuvent être manquantes.
Spéculative de la Hiérarchie: Cette odeur survient lorsque un ou plusieurs types de hiérarchie sont fournis sur la spéculation (c'est à dire, basé sur imaginé besoins plutôt que de besoins réels).
Hiérarchie Profonde: Cette odeur se pose lorsqu'une hiérarchie d'héritage est "trop" de profondeur.
Rebelle de la Hiérarchie: Cette odeur se pose lorsqu'un sous-type rejette les méthodes fournies par ses supertype(s).
Cassé la Hiérarchie: Cette odeur se pose lorsqu'un supertype et de ses sous-type conceptuellement ne partagent pas un "EST - UN" de la relation résultant en une substituabilité cassée.
hiérarchie des voies multiples: cette odeur apparaît lorsqu'un sous-type hérite à la fois directement et indirectement d'un sur-Type conduisant à des voies d'héritage inutiles dans la hiérarchie.
Cyclique de la Hiérarchie: Cette odeur se pose lorsqu'un supertype dans une hiérarchie dépend de l'une quelconque de ses sous-types.
ci-dessus définition et classification est décrite dans "Refactoring pour la conception de logiciels odeurs: la Gestion de la dette technique ". Des ressources plus pertinentes peuvent être trouvées ici .
Un modèle est une idée de comment 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 parce que la mise en œuvre de cette idée se traduirait par une mauvaise conception.
Un exemple: un "modèle" serait d'utiliser une fonction pour la réutilisation du code, un "anti-modèle" serait d'utiliser le copier-coller pour la même chose. 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 copier-coller.
un modèle anti-est une façon de ne pas résoudre un problème. Mais il y a plus: c'est aussi une voie que l'on voit souvent dans les tentatives de résoudre le problème.
si vous souhaitez vraiment étudier les Antimodèles, consultez le livre Antimodèles (ISBN-13: 978-0471197133).
dans ce, ils définissent "un Antimodèle est une forme littéraire qui décrit une solution courante à un problème qui génère décidément des conséquences négatives."
donc, si c'est une mauvaise pratique de programmation mais pas une pratique commune-limitée à une application, une compagnie ou un programmeur, il ne répond pas aux "Motif" partie de la définition Anti-modèle.
une façon courante de faire un gâchis. Comme la classe de Dieu / kitchensink (fait tout), par exemple.
Un anti-modèle est le complément d'un modèle de conception . Un anti-pattern est une solution de modèle que vous ne devriez pas utiliser dans une certaine situation.
tout comme avec un design pattern , un anti-pattern est également un modèle et une façon reproductible de résoudre un certain problème, mais d'une manière non-optimale et inefficace.
il est intéressant de noter qu'une façon donnée de résoudre un problème peut être à la fois un modèle et un modèle anti-modèle. Singleton en est le premier exemple. Elle apparaîtra dans les deux séries de documents.
Aujourd'hui, les chercheurs et les praticiens en génie logiciel utilisent souvent les Termes "anti-modèle" et "odeur" de façon interchangeable. Cependant, ils sont théoriquement pas les mêmes. La page Wikipédia de l'anti-modèle stipule qu'un anti-modèle est différent d'une mauvaise pratique ou une mauvaise idée par au moins deux facteurs. Un anti-pattern est
" un processus, une structure ou un schéma d'action couramment utilisé qui, malgré figurant initialement être approprié et réponse efficace à un problème, a généralement plus de mauvaises conséquences que des résultats bénéfiques."
il indique clairement qu'un modèle anti-patron est choisi dans la croyance qu'il est une bonne solution (comme un modèle) au problème présenté; cependant, il apporte plus de responsabilités que les avantages. Sur l'autre main, l'odeur est tout simplement une mauvaise pratique qui affecte négativement la qualité d'un système logiciel. Par exemple, le Singleton est un anti-modèle et classe de Dieu (ou modularisation insuffisante) est une odeur de conception.
anti-patterns sont des façons courantes les gens ont tendance à programmer de la mauvaise façon, ou du moins pas si bonne.
tout modèle de conception qui fait plus de mal que de bien à l'environnement de développement de logiciel donné serait considéré comme anti-modèle.
certains motifs contraires sont évidents, mais d'autres ne le sont pas. Par exemple Singleton, même si beaucoup le considèrent bon vieux modèle de conception, mais il ya d'autres qui ne le font pas.
Vous pouvez vérifier la question Ce qui est si mal à propos de singletons? pour mieux comprendre les différentes opinions à ce sujet.