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.¿Qué es un antipatrón?
¿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?
Anti-patterns son ciertos patrones en el desarrollo de software que se consideran malas prácticas de programación.
A diferencia de design patterns 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 God object 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 lo . 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 frecuencia patrones usados (design patterns), pero también hay maneras 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.
¿algún otro ejemplo de Anti-Patrones al lado de GodObject? – Tomasz
@Tomasz La programación de Pasta sirve es uno de esos ejemplos. Lo mejor es generalizar como una pobre encapsulación entre muchos objetos pequeños. Consideramos que es lo contrario de Dios el objeto https://en.wikipedia.org/wiki/Spaghetti_code – AWrightIV
@Tomasz todo lo que es malo, pero se hace por algunas personas, es un anti patrón. Por ejemplo, 'try:
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 "antipatró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.
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.
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.
Si realmente desea estudiar AntiPatterns, obtenga el libro AntiPatterns (ISBN-13: 978-0471197133).
En ella, definen "Un AntiPattern es una forma literaria que describe una solución común a un problema que genera consecuencias decididamente negativas."
lo tanto, si se trata de una mala práctica de programación, pero no uno común — limitada a una aplicación, una empresa o un programador, no se ajusta a la 'parte del patrón' de la definición anti patrón.
Curiosamente una La forma determinada de resolver un problema puede ser tanto un patrón como un antipatrón: Singleton es el mejor ejemplo de esto. Aparecerá en ambos grupos de literatura.
Los antipatrones son formas comunes en que las personas tienden a programar un error manera, o al menos la manera no tan buena.
Siempre que escucho sobre Anti- patrones, recuerdo otro término a saber. Olor de diseño .
"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 de Diseño de Software Olores: La gestión de la deuda técnica')
Hay muchos olores de diseño clasifican sobre la base de que viola los principios de diseño:
Abstracción huele
Missing Abstracción: surge Este olor cuando grupos de datos o str codificada Los registros se usan en lugar de crear una clase o una interfaz.
Imperativo Abstracción: Este olor surge cuando una operación se convierte en una clase.
Abstracción incompleta: Este olor surge cuando una abstracción no admite métodos complementarios o interrelacionados por completo.
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 utiliza (no se usa directamente o no se puede acceder).
Abstracción duplicada: Este olor surge cuando dos o más abstracciones tienen nombres idénticos o implementación idéntica o ambas.
encapsulación huele
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.
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 perdida: Este olor se produce cuando las variaciones de implementación no se encapsulan en una abstracción o jerarquía.
encapsulación no explotado: Este olor surge cuando el código de cliente utiliza los controles de tipo explícita (usando cadena si-else o conmutador declaraciones que comprueban para el tipo del objeto) en lugar de explotar la variación en los tipos ya encapsulados dentro de una jerarquía.
modularización huele
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.
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 de Hub-like: Este olor surge cuando una abstracción tiene dependencias (tanto entrantes como salientes) con una gran cantidad de otras abstracciones.
Jerarquía huele
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 se usa para encapsular esas variaciones.
Jerarquía innecesaria: Este olor surge cuando la jerarquía de herencia completa no es necesaria, lo que indica que la herencia se ha aplicado innecesariamente para el contexto de diseño particular.
Jerarquía no modificada: Este olor surge cuando hay una duplicación innecesaria entre los tipos en una jerarquía.
Gran jerarquía: 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 la clasificación anterior se describe en "Refactoring for software design smells: Managing technical debt". Algunos recursos más relevantes podrían ser encontrados here.
Un anti-patrón es el complemento de un patrón diseño. Un anti- patrón es una solución de la plantilla no se debe utilizar en una situación determinada.
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 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 de uso común, la estructura o patrón de acción que a pesar de inicialmente parece ser una respuesta apropiada y efectiva a un problema , típicamente tiene más malas consecuencias que resultados beneficiosos.”
se indica claramente que un anti-patrón se eligió creyendo que es una buena solución (como un patrón) para el problema planteado;. Sin embargo, trae más pasivos que los beneficios por otro lado, un olor es simplemente una mala práctica que afecta negativamente la calidad de un softwa re sistema. Por ejemplo, Singleton es un antipatrón y la clase de Dios (o modulación insuficiente) es un olor de diseño.
https://sourcemaking.com/antipatterns – jaco0646
http://martinfowler.com/bliki/AntiPattern.html – jaco0646