design patterns - patterns - ¿Qué es un antipatrón?
lista de antipatrones (12)
Al igual que con un patrón de diseño , un antipatrón es también una plantilla y una forma repetible de resolver un determinado problema, pero de una manera no óptima e ineficaz.
Estoy estudiando patrones y antipatrones. Tengo una idea clara sobre los patrones, pero no tengo antipatrones. Las definiciones de la web y Wikipedia me confunden mucho.
¿Alguien puede explicarme en palabras simples lo que es un antipatrón? ¿Cuál es el propósito? ¿Qué hacen? ¿Es algo malo o bueno?
Cada vez que escucho sobre Anti-patrones, recuerdo otro término a saber. Olor de diseño
"Los olores de diseño son ciertas estructuras en el diseño que indican la violación de los principios de diseño fundamentales y afectan negativamente a la calidad del diseño". (De "Refactorización para olores de diseño de software: gestión de deuda técnica")
Hay muchos olores de diseño clasificados según principios de diseño infractores:
Abstracción huele
Abstracción perdida: este olor surge cuando se usan grupos de datos o cadenas codificadas en lugar de crear una clase o una interfaz.
Abstracción Imperativa: Este olor surge cuando una operación se convierte en una clase.
Abstracción incompleta: este olor surge cuando una abstracción no admite completamente los métodos complementarios o interrelacionados.
Abstracción multifacética: este olor surge cuando una abstracción tiene asignada más de una responsabilidad.
Abstracción innecesaria: este olor se produce cuando una abstracción que en realidad no es necesaria (y por lo tanto podría haberse evitado) se introduce en un diseño de software.
Abstracción no utilizada: este olor surge cuando una abstracción no se usa (ya sea que no se usa directamente o no se puede alcanzar).
Abstracción duplicada: este olor surge cuando dos o más abstracciones tienen nombres idénticos o implementación idéntica o ambas.
Olores de encapsulación
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 de lo que realmente se requiere.
Encapsulación con fugas: este olor surge cuando una abstracción "expone" o "filtra" detalles de la implementación a través de su interfaz pública.
Encapsulación faltante: este olor se produce cuando las variaciones de implementación no están encapsuladas dentro de una abstracción o jerarquía.
Encapsulación no explotada: este olor surge cuando el código del cliente utiliza comprobaciones de tipo explícitas (utilizando sentencias if-else encadenadas o conmutadas que comprueban el tipo del objeto) en lugar de explotar la variación en tipos ya encapsulados dentro de una jerarquía.
Olores de modulación
Modularización rota: este olor surge cuando los datos y / o métodos que idealmente deberían haberse localizado en una única abstracción se separan y se distribuyen en múltiples abstracciones.
Modularización insuficiente: este olor surge cuando existe una abstracción que no se ha descompuesto completamente, y una descomposición adicional podría reducir su tamaño, complejidad de implementación o ambas.
Modularización cíclicamente dependiente: Este olor surge cuando dos o más abstracciones dependen una de la otra directa o indirectamente (creando un estrecho acoplamiento entre las abstracciones).
Modularización tipo Hub: este olor surge cuando una abstracción tiene dependencias (tanto entrantes como salientes) con una gran cantidad de otras abstracciones.
Huele la jerarquía
Jerarquía perdida: este olor surge cuando un segmento de código usa lógica condicional (generalmente junto con "tipos etiquetados") para administrar explícitamente la variación en el comportamiento donde podría haberse creado una jerarquía y usarse para encapsular esas variaciones.
Jerarquía innecesaria: este olor surge cuando toda la jerarquía de herencia es innecesaria, lo que indica que la herencia se ha aplicado innecesariamente para el contexto de diseño particular.
Jerarquía no factorizada: este olor surge cuando hay una duplicación innecesaria entre los tipos en una jerarquía.
Jerarquía amplia: este olor surge cuando una jerarquía de herencia es "demasiado" amplia, lo que indica que pueden faltar tipos intermedios.
Jerarquía especulativa: este olor surge cuando uno o más tipos en una jerarquía se proporcionan especulativamente (es decir, en función de las necesidades imaginarias en lugar de los requisitos reales).
Jerarquía profunda: este olor surge cuando una jerarquía de herencia es "excesivamente" profunda.
Jerarquía rebelde: este olor surge cuando un subtipo rechaza los métodos provistos por su (s) su (s) tipo (s).
Jerarquía rota: Este olor surge cuando un supertipo y su subtipo conceptualmente no comparten una relación "IS-A" que da como resultado una sustituibilidad rota.
Jerarquía de múltiples rutas: este olor surge cuando un subtipo hereda tanto directa como indirectamente de un supertipo que conduce a rutas de herencia innecesarias en la jerarquía.
Jerarquía cíclica: este olor surge cuando un supertipo en una jerarquía depende de cualquiera de sus subtipos.
La definición y clasificación anterior se describe en "Refactorización para olores de diseño de software: gestión de deuda técnica ". Se pueden encontrar algunos recursos más relevantes here .
Cualquier patrón de diseño que esté haciendo más daño que bien al entorno de desarrollo de software dado se consideraría como antipatrón.
Algunos antipatrones son obvios, pero otros no. Por ejemplo, Singleton, aunque muchos lo consideran un buen patrón de diseño antiguo, pero hay otros que no lo tienen.
Puede consultar la pregunta ¿Qué tiene de malo los singletons? para comprender mejor las diferentes opiniones sobre él.
Curiosamente, una forma determinada de resolver un problema puede ser tanto un patrón como un antipatrón. Singleton es el principal ejemplo de esto. Aparecerá en ambos conjuntos de literatura.
Hoy en día, los investigadores y practicantes de ingeniería de software a menudo usan los términos "antipatrón" y "olfato" indistintamente. Sin embargo, conceptualmente no son lo mismo. La entrada de Wikipedia de anti-patrón establece que un antipatrón es diferente de una mala práctica o una mala idea por al menos dos factores. Un anti-patrón es
"Un proceso, estructura o patrón de acción comúnmente utilizado que, a pesar de que inicialmente parece ser una respuesta apropiada y efectiva a un problema, generalmente tiene más malas consecuencias que resultados beneficiosos".
Indica claramente que se elige un antipatrón en la creencia de que es una buena solución (como patrón) para el problema presentado; sin embargo, trae más responsabilidades que beneficios. Por otro lado, un olor es simplemente una mala práctica que afecta negativamente la calidad de un sistema de software. Por ejemplo, Singleton es un antipatrón y la clase de Dios (o modulación insuficiente) es un olor de diseño.
Los antipatrones son formas comunes en que las personas tienden a programar de manera incorrecta, o al menos no tan bien.
Si realmente deseas estudiar AntiPatterns, obtén el libro AntiPatterns (ISBN-13: 978-0471197133).
En él, definen "Un AntiPattern es una forma literaria que describe una solución común a un problema que genera consecuencias decididamente negativas".
Por lo tanto, si se trata de una mala práctica de programación, pero no es común, se limita a una aplicación, una empresa o un programador, no cumple con la parte "Patrón" de la definición de AntiPattern.
Un antipatrón es el complemento de un patrón de diseño . Un antipatrón es una solución de plantilla que no debe usar en una situación determinada.
Un antipatrón es una forma de no resolver un problema. Pero hay más: también es una forma que se puede ver con frecuencia en los intentos de resolver el problema.
Un patrón es una idea de cómo resolver un problema de alguna clase. Un antipatrón es una idea de cómo no resolverlo porque la implementación de esa idea daría como resultado un mal diseño.
Un ejemplo: un "patrón" sería usar una función para la reutilización de código, un "anti-patrón" sería usar copiar y pegar para el mismo. Ambos resuelven el mismo problema, pero el uso de una función generalmente conduce a un código más legible y mantenible que copiar y pegar.
Una forma común de hacer un lío. Al igual que la clase de dios / kitchensink (hace todo), por ejemplo.
Anti-patterns 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 que son enfoques comunes a los problemas comunes que se han formalizado y que generalmente se consideran una buena práctica de desarrollo, los antipatrones son lo contrario y son indeseables.
Por ejemplo, en la programación orientada a objetos, la idea es separar el software en pequeñas piezas llamadas objetos. Un anti-patrón en la programación orientada a objetos es un objeto de Dios que realiza muchas funciones que se separarían mejor en objetos diferentes.
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 menos acoplado 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 software con patrones comúnmente utilizados (patrones de diseño ), pero también hay formas en que se desarrolla e implementa el software que puede ocasionar problemas. Los patrones que se consideran malas prácticas de desarrollo de software son antipatrones.