¿Qué es un anti-patrón?
https://stackoverflow.com/questions/980601
-
13-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Soy patrones que estudian y anti-patrones. Tengo una idea clara acerca de los patrones, pero no consigo anti-patrones. Las definiciones de la Web y Wikipedia me confunden mucho.
¿Alguien puede explicarme en palabras sencillas lo que un anti-patrón es? ¿Cuál es el propósito? ¿Qué hacen? ¿Es algo malo o bueno?
Solución
anti-patrones son ciertos patrones en el desarrollo de software que se consideran malas prácticas de programación.
A diferencia de los patrones de diseño, enfoques que son comunes a los problemas comunes que han sido formalizada y generalmente se consideran una buena práctica de desarrollo, anti-patrones son lo contrario y son indeseables.
Por ejemplo, en la programación orientada a objetos, la idea es separar el software en trozos pequeños llamados objetos. Un anti-patrón en la programación orientada a objetos es una Dios objeto que realiza una gran cantidad de funciones que lo haría ser mejor separados en diferentes objetos.
Por ejemplo:
class GodObject {
function PerformInitialization() {}
function ReadFromFile() {}
function WriteToFile() {}
function DisplayToScreen() {}
function PerformCalculation() {}
function ValidateInput() {}
// and so on... //
}
El ejemplo anterior tiene un objeto que hace todo . En la programación orientada a objetos, sería preferible tener responsabilidades bien definidas para diferentes objetos para mantener el código de menos vinculada y en última instancia, más fácil de mantener:
class FileInputOutput {
function ReadFromFile() {}
function WriteToFile() {}
}
class UserInputOutput {
function DisplayToScreen() {}
function ValidateInput() {}
}
class Logic {
function PerformInitialization() {}
function PerformCalculation() {}
}
La conclusión es que hay buenas maneras de desarrollar el software con los patrones de uso común (patrones de diseño href="http://en.wikipedia.org/wiki/Design_pattern_(computer_science)" rel="noreferrer"> ), pero también hay formas de software y pone en práctica lo que puede conducir a problemas. Patrones que se consideran prácticas de desarrollo de software son un mal anti-patrones.
Otros consejos
Cada vez que escucho acerca de anti-patrones, a saber Recuerdo otra plazo. Diseño olor.
"olores de diseño son ciertas estructuras en el diseño que indican violación de los principios fundamentales de diseño e influir negativamente en la calidad del diseño.” (De 'Refactoring para el software de Diseño Olores: La gestión de la deuda técnica')
Hay muchos diseño olores clasificado sobre la base de que viola los principios de diseño:
Abstracción olores
Abstracción Missing:. surge Este olor cuando se utilizan grupos de datos o cadenas codificadas en lugar de crear una clase o una interfaz
Abstracción imperativo:. surge Este olor cuando una operación se convierte en una clase
Abstracción incompleta: surge Este olor cuando una abstracción no soporta métodos complementarios o interrelacionados completamente
.polifacético Abstracción: Esto surge olor cuando una abstracción tiene más de una responsabilidad asignada a ella
.abstracción innecesaria:. Este olor se produce cuando una abstracción que en realidad no se necesita (y por lo tanto se podría haber evitado) se introdujo en un diseño de software
Abstracción no utilizada: surge Este olor cuando una abstracción se deja sin utilizar (ya sea no se utiliza directamente o no alcanzable)
.Duplicar Abstracción:. surge Este olor cuando dos o más abstracciones tienen nombres idénticos o aplicación idéntica o ambos
La encapsulación olores
La encapsulación Deficiente:. Este olor se produce cuando la accesibilidad declarada de uno o más miembros de una abstracción es más permisiva que realmente se requiere
La encapsulación Leaky:. Esto surge olor cuando una abstracción “revelaciones” o “fugas” detalles de implementación a través de su interfaz pública
Encapsulación Missing: Este olor se produce cuando las variaciones de implementación no se encapsulan dentro de una abstracción o jerarquía
.encapsulación no explotado: surge Este olor cuando el código de cliente utiliza los controles de tipo explícita (usando encadenados si-else o cambiar las declaraciones que comprueban para el tipo del objeto) en lugar de explotar la variación en los tipos ya encapsulado dentro de una jerarquía.
La modularización olores
modularización Roto:. surge Este olor cuando los datos y / o métodos que idealmente debería haber sido localizadas en un único abstracción se separan y se extienden a través de múltiples abstracciones
La modularización insuficiente:. Esto surge olor cuando existe una abstracción que no ha sido completamente descompuesto, y una descomposición adicional podría reducir su tamaño, complejidad de la implementación, o ambos
modularización en función del ciclo dependiente:. surge Este olor cuando dos o más abstracciones dependen unos de otros, directa o indirectamente (la creación de un acoplamiento hermético entre las abstracciones)
a modo de cubo modularización:. Esto surge olor cuando una abstracción tiene dependencias (tanto entrantes como salientes) con un gran número de otras abstracciones
Jerarquía olores
Jerarquía Missing: surge Este olor cuando un segmento de código utiliza la lógica condicional (típicamente en conjunción con “etiquetado tipos”) para administrar explícitamente variación en el comportamiento donde podría haberse creado una jerarquía y utilizado para encapsular esas variaciones.
Jerarquía innecesario:. surge Este olor cuando toda la jerarquía de herencia es innecesario, lo que indica que la herencia se ha aplicado innecesariamente para el contexto particular diseño
sin ponderar Jerarquía: surge Este olor cuando hay duplicación innecesaria entre los tipos en una jerarquía
.ancha Jerarquía: surge Este olor cuando una jerarquía de herencia es “demasiado” de ancho que indica que tipos intermedios pueden faltar
.Jerarquía especulativa: Esta smell surge cuando se proporcionan uno o más tipos en una jerarquía especulativamente (es decir, basado en las necesidades imaginadas en lugar de requisitos reales).
jerarquía profunda: surge Este olor cuando una jerarquía de herencia es “excesivamente” de profundidad
.Jerarquía rebelde: surge Este olor cuando un subtipo rechaza los métodos proporcionados por su supertipo (s)
.Jerarquía Roto:. surge Este olor cuando un supertipo y su subtipo conceptualmente no comparten una relación “IS- A” que resulta en sustitución roto
Multipath Jerarquía:. surge Este olor cuando un subtipo hereda tanto directamente como indirectamente a partir de un supertipo conduce a trayectorias de herencia innecesarios en la jerarquía
cíclica Jerarquía:. surge Este olor cuando un supertipo en una jerarquía depende de cualquiera de sus subtipos
La definición y la clasificación anterior se describe en href="https://rads.stackoverflow.com/amzn/click/com/0128013974" "Refactoring para el diseño de software huele: Gestión de la deuda técnica ". Algunos de los recursos más relevantes se podrían encontrar aquí .
Un modelo es una idea de cómo resolver un problema de alguna clase. Un anti-patrón es una idea de cómo no hay que resolverlo porque la aplicación de esa idea podría resultar en un mal diseño.
Un ejemplo: un "patrón" sería el uso de una función para la reutilización de código, un "anti-patrón" sería el uso de copiar y pegar para el mismo. Tanto resolver el mismo problema, pero utilizando una función por lo general conduce a un código más legible y fácil de mantener que copiar y pegar.
Un anti-patrón es una forma de no resolver un problema. Pero hay más que eso:. También es una manera de que con frecuencia se puede ver en los intentos de resolver el problema
Si realmente desea estudiar antipatrones, conseguir el libro antipatrones (ISBN-13: 978-0471197133).
En él, definen "An antipatrón es una forma literaria que describe una solución que ocurren comúnmente a un problema que genera consecuencias decididamente negativas."
Por lo tanto, si se trata de una mala práctica de programación, pero no uno común limitado a una aplicación, una empresa o un programador, no se ajusta a la parte de "patrón" de la definición anti patrón.
Una forma común de hacer un lío. Al igual que la clase de dios / KitchenSink (hace todo), por ejemplo.
Un anti-patrón es el complemento de un patrón de diseño . Un anti-patrón es una solución de la plantilla no se debe utilizar en una situación determinada.
Al igual que con un patrón de diseño , un anti-patrón es también una plantilla y una forma repetible de la solución de un problema determinado, pero de una manera no óptima e ineficaz camino.
Curiosamente una determinada manera de resolver un problema puede ser tanto un patrón y un anti-patrón. Singleton es el principal ejemplo de esto. Aparecerá en ambos conjuntos de literatura.
Hoy en día, los investigadores de ingeniería de software y profesionales a menudo usan los términos “anti-patrón” y “olor” de manera intercambiable. Sin embargo, conceptualmente no son los mismos. La entrada de Wikipedia de anti-patrón indica que un anti-patrón es diferente de una mala práctica o una mala idea por lo menos dos factores. Un anti-patrón es
"Un proceso, estructura o patrón de acción utilizado comúnmente que a pesar inicialmente parece ser una respuesta apropiada y eficaz a una problema, por lo general tiene más malas consecuencias que los resultados beneficiosos “.
Se indica claramente que un anti-patrón se elige en la creencia de que es una buena solución (como un patrón) para el problema presentado; Sin embargo, trae más pasivos que beneficios. Por otra parte, un olor es simplemente una mala práctica que afecta negativamente la calidad de un sistema de software. Por ejemplo, Singleton es un anti-patrón y la clase de Dios (o modularización insuficiente) es un olor diseño.
Anti-patrones son formas comunes de la gente tiende a programar de manera incorrecta, o al menos no tan buena forma.
Cualquier patrón de diseño que está haciendo más daño que bien al entorno de desarrollo de software dada sería considerado como anti-patrón.
Algunos anti-patrón son evidentes, pero algunos no lo son. Por ejemplo Singleton, a pesar de que muchos consideran que es un buen patrón de diseño antiguo, pero hay otros que no lo hacen.
Puede comprobar pregunta ¿Qué hay de malo en embarazos únicos? a una mejor entender las diferentes opiniones sobre él.
Al igual que en el algoritmo se puede lograr la solución usando la fuerza bruta, pero usted tiene que pagar mucho si se convierten en situación compleja.
