Capítulo 4. Antipatrones
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Como ingenieros, podemos encontrarnos con situaciones en las que tenemos un plazo límite para entregar una solución o en las que el código se incluye como una serie de parches sin una revisión del código. En estos casos, el código no siempre está bien pensado y puede propagar lo que llamamos antipatrones. Este capítulo describe qué son los antipatrones y por qué es esencial comprenderlos e identificarlos. También veremos algunos antipatrones típicos enJavaScript.
¿Qué son los antipatrones?
Si un patrón representa una buena práctica, un anti-patrón representa la lección aprendida cuando un patrón propuesto sale mal. Inspirándose en el libro Design Patterns (Patrones de diseño) del GoF, Andrew Koenig acuñó por primera vez el término antipatrón en 1995 en su artículo del volumen 8 delJournal of Object-Oriented Programming. Describió los antipatrones como
Un antipatrón es igual que un patrón, salvo que, en lugar de una solución, da algo que superficialmente parece una solución, pero no lo es.
Presentó dos nociones de antipatrones. Antipatrones:
-
Describe una mala solución a un problema concreto que provocó una situación desfavorable
-
Describe cómo salir de dicha situación y llegar a una buena solución
Sobre este tema, Alexander escribe acerca de las dificultades para lograr un buen equilibrio entre una buena estructura de diseño y un buen contexto:
Estas notas tratan sobre el proceso de diseño; el proceso de inventar cosas físicas que muestren un nuevo orden físico, una organización, una forma, en respuesta a una función. ... Todo problema de diseño comienza con un esfuerzo por lograr la adecuación entre dos entidades: la forma en cuestión y su contexto. La forma es la solución al problema; el contexto define el problema.
Comprender los antipatrones es tan esencial como conocer los patrones de diseño. Maticemos la razón de ello. Al crear una aplicación, el ciclo de vida de un proyecto comienza con la construcción. En esta fase, es probable que elijas entre los buenos patrones de diseño disponibles, según te convenga. Sin embargo, tras el lanzamiento inicial, es necesario mantenerla.
El mantenimiento de una aplicación que ya está en producción puede ser especialmente difícil. Los desarrolladores que no hayan trabajado antes en la aplicación pueden introducir accidentalmente un mal diseño en el proyecto. Si estas malas prácticas ya se han identificado como antipatrones, los desarrolladores las reconocerán de antemano y evitarán los errores comunes conocidos. Esto es similar a cómo el conocimiento de los patrones de diseño nos permite reconocer áreas en las que podríamos aplicar técnicas estándar conocidas y útiles.
La calidad de la solución a medida que evoluciona será buena o mala, dependiendo del nivel de habilidad y del tiempo que el equipo haya invertido en ella. Aquí, lo bueno y lo malo se consideran en contexto: un diseño "perfecto" puede calificarse de antipatrón si se aplica en el contexto equivocado.
En resumen, un antipatrón es un mal diseño que merece ser documentado.
Antipatrones en JavaScript
Los desarrolladores a veces optan a sabiendas por atajos y soluciones temporales para acelerar las entregas de código. Éstas tienden a convertirse en permanentes y a acumularse como deuda técnica que se compone esencialmente de antipatrones. JavaScript es un lenguaje débilmente tipado o no tipado, lo que facilita tomar ciertos atajos. Estos son algunos ejemplos de antipatrones que puedes encontrar en JavaScript:
-
Contaminar el espacio de nombres global definiendo numerosas variables en elcontexto global.
-
Pasar cadenas en lugar de funciones a
setTimeout
osetInterval
, ya que esto desencadena el uso deeval()
internamente. -
Modificar el prototipo de la clase
Object
(éste es un antipatrón especialmente malo). -
Utilizar JavaScript en un formulario inline, ya que es inflexible.
-
El uso de
document.write
cuando las alternativas nativas del Modelo de Objetos del Documento (DOM), comodocument.createElement
, son más apropiadas.document.write
se ha utilizado muy mal a lo largo de los años y tiene bastantes desventajas. Si se ejecuta después de que se haya cargado la página, puede sobrescribir la página en la que estamos, lo que hace quedocument.createElement
sea una opción mucho mejor. Visita este enlace para ver un ejemplo en vivo de esto en acción. Tampoco funciona con XHTML, que es otra razón por la que optar por métodos más respetuosos con el DOM comodocument.createElement
es favorable.
El conocimiento de los antipatrones es fundamental para el éxito. Una vez que aprendemos a reconocer esos antipatrones, podemos refactorizar nuestro código para anularlos, de modo que la calidad general de nuestras soluciones mejore al instante.
Resumen
En este capítulo se han tratado los patrones que pueden causar problemas, conocidos como antipatrones, y ejemplos de antipatrones de JavaScript. Antes de tratar en detalle los patrones de diseño de JavaScript, debemos tocar algunos conceptos críticos del JavaScript moderno que resultarán relevantes para nuestro debate sobre los patrones. Éste es el tema del siguiente capítulo, que presenta las características y la sintaxis modernas de JavaScript.
Get Aprender patrones de diseño de JavaScript, 2ª edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.