martes, 26 de octubre de 2010

Antipatrones de Diseño

Definición: Un antipatrón es una solución negativa a un problema de desarrollo de software. Existen antipatrones de administración, diseño, programación, gestión de proyectos.

71 comentarios:

  1. Código ravioli (Ravioli code)

    El código ravioli se apega perfectamente a la analogía siguiente: los raviolis son pequeños paquetes que contienen carne, vegetales y queso. También un sistema o aplicación basados en este anti patrón poseen objetos que se encapsulan contienen módulos que constan de código y datos. En este anti patrón se crean demasiadas funciones que a la hora de solventar un problema las personas se confunden porque no saben donde ha ocurrido el problema en el código fuente, no hay un orden para codificar las clases necesarias y se agregan funciones de una manera incorrecta, por lo anterior se origina el anti patrón código ravioli.
    Ejemplo:
    Cuando se codifica una calculadora científica, se agregan muchas funciones aritméticas y propias de este tipo de calculadora, las cuales si solo se adicionan sin ningún orden y no se ocupan las clases que idealmente se necesiten, cuando haya un problema en una función cualquiera, tendremos más dificultad de encontrar la el bloque de código que esté dando inconvenientes a la hora de ejecutar la calculadora científica.

    por: Carlos Alfredo Perez Alfaro

    ResponderEliminar
  2. Antipatrón de Programación

    Momento del código (Code Momentum)

    Establece demasiadas restricciones sobre una parte del sistema debido a la asunción de muchas de sus propiedades desde otros lugares del propio sistema.

    Ejemplo:
    En un sistema de una empresa "XY" se emplea ó se le adjudica a cada empleado un usuario y contraseña para realizar cada una de las siguientes operaciones: Ingresar al sistema, Registrar una venta; registrar una adquisición de mercaderia (compra); Registrar la entrada y salida a la empresa por cada uno de sus empleados, etc.

    El sistema funciona de la siguiente manera al momento que el empleado ingresa su usuario y contraseña incorrectamente por lógica no puede accesar al sistema y al ingresar correctamente el usuario y contraseña accesa al sistema, y al registrar una compra ó venta ó registrar su entrada y salida el sistema le solicitará al empleado su usuario y contraseña al ingresar correctamente podra registrar las operaciones del sistema antes mencionadas en caso contrario volvera a la pantalla principal.-

    Víctor Hugo Sosa Figueroa. SMIS041208

    ResponderEliminar
  3. Código spaghetti


    El código spaghetti es un término para los programas de computación que tienen una estructura de control de flujo compleja e incomprensible. Su nombre deriva del hecho que este tipo de código parece asemejarse a un plato de espaguetis, es decir, un montón de hilos intrincados y anudados..
    Sin embargo, se debe tener en cuenta que hoy, con lenguajes modernos como PHP, SQL, JavaScript (su última versión) junto con HTML (incluyendo su última versión), el código spaghetti es cada vez más utilizado ya que muchas veces estos lenguajes deben quedar entrelazados, aunque es perfectamente posible que un programador experimentado evite esto aunque se requiera para ello de un poco más de esfuerzo de programación que al final viene a ser recompensado con una programación más limpia, fácilmente entendible que le beneficia incluso a él mismo a la hora de dar mantenimiento a los sistemas.


    Melvin Amílcar Molina Romero

    ResponderEliminar
  4. El problema de este antiatron que el código del programa que se activa en modo oculto sin poder verlo fácilmente y resulta muy difícil a la hora de poder modificar el código
    Y probablemente el usuario espera una respuesta de un programa y el programa le le da otra

    EJEMPLO
    Por ejemplo: Un desarrollador escribe un programa que crea formas pidiendo información variada, llena de cuadros de texto en varios, para obtener más información acerca de los clientes.


    La especificación de usuario requiere que si algún formulario tiene un cuadro de texto en blanco, que la aplicación de forma que se elimina en particular. De lo contrario la aplicación compila junto completado todas las formas y los guarda en un archivo (tal vez una base de datos) cuando el usuario hace clic en cualquiera de los 'salvar' botones. El formulario tiene un botón y un botón y mostrar una alerta si un cuadro de texto está vacío.

    Jimmy erick Zelaya alvarez

    ResponderEliminar
  5. BOMQ (Batch Over MQ): funciona en el empleo de integración basada en mensajes en tiempo real para transferencias esporádicas de gran tamaño en segundo plano.

    marvin leonardo aparicio smis058508

    ResponderEliminar
  6. Acción a distancia (action at a distance): Provocar la interacción no prevista de componentes muy distantes de un sistema. cuando hablamos de interaccion no prevista nos referimos a una comunicacion no necesaria en sistema

    Juan Jose Medina escobar
    codigo: smis011208

    ResponderEliminar
  7. Nomenclatura heroica : Identifica los miembros de un programa (interfaces, clases, propiedades y métodos) con nombres que provocan que el conjunto aparente estandarización en la ingeniería de software pero que en realidad oculta una implementación anárquica.


    Ejemplo: Una tienda posee varios productos que se pueden vender y comprar por un cliente; los cuales son heredados por un proveedor. Los productos poseen las mismas propiedades, campos y métodos lo único que varia es su valor y desempeño como los siguientes:
    lácteo: leche, queso, crema…etc.
    y
    golosinas: dulces, chocolates, caramelos… etc.

    Hugo Edenilson Jurado Martinez
    Codigo:smis003708

    ResponderEliminar
  8. Sistema de cañerías de calefacción (stovepipe system);
    Es un sistema heredado que no se puede actualizar o rediseñado y que debe ser construido alrededor hasta que pueda ser sustituido en su totalidad.
    Ej;
    Una colección de componentes o elementos que se integran a tal grado que ya no es posible diferenciar o modificarlos, Debido al grado de integración, que no se puede actualizar, y sólo un sistema completamente nuevo puede sustituir.

    -César Antonio Girón Argueta.
    -SMIS044208

    ResponderEliminar
  9. LA COMPLEJIDAD NO INDISPENSABLE En Computación, el antipatrón de diseño Accidental complexity o Complejidad no indispensable describe la situación a la que se llega cuando en el desarrollo de una aplicación se selecciona un camino de complejidad mayor que la indispensable. En algunos casos, la complejidad es inherente al problema, pero también ocurre que ésta se introduce por desconocimiento o por problemas de planificación. Una situación como ésta, si no es reconocida, puede fácilmente hacer cancelar un proyecto.
    JOEL ALEXANDER ORTIZ HERNANDEZ smis025908

    ResponderEliminar
  10. Antipatron Llamar a Super (CallSuper)

    Llamar a super es un antipatron de la programación orientada a objetos (OOP ). Llamar a super es un antipatron de diseño en el que una clase particular establece que en una subclse derivada, el usuario tiene la obligación de reemplazar un método y devolver la llamada a la función se reemplaza en si en un punto determinado. El método reemplazado puede ser intercionalmente incompleta, y depende en el método primordial para aumentar su funcionalidad en la forma prescrita. Sin embargo el hecho de que el lenguaje en si mismo puede no ser capaz de cumplir todas las condiciones requeridas en la presente convocatorio es lo que hace de este un antipatron.

    Ejemplo

    Este archivo vemos como implementamos el antipatron en C#

    http://www.megaupload.com/?d=Z366IZU7

    Mario Ernesto Flores Chevez SMIS041008

    ResponderEliminar
  11. INFIERNO DLL.
    El infierno DLL son los conflictos que tienen que ver con *.dll (Dynamic Link Library, Biblioteca de Enlace Dinámico) en los OS MS específicamente, que poco a pueden volver al sistema inestable hasta la famosa pantalla azul de Windows.
    Las dll con un conjunto de código común que puede estar compartido entre varias aplicaciones. En Windows estas bibliotecas están muy extendidas y son compartidas por múltiples aplicaciones (por ejemplo, las MFC están compartidas por prácticamente todas las aplicaciones gráficas).
    De esta necesidad de compartir código surge el infierno:
    Al instalar un programa se reemplaza una DLL por otra versión incompatible (conflicto de versiones).
    Al desinstalar un programa se borra una DLL compartida.
    Esto hace que muchos programas no puedan funcionar.

    Existe un conjunto de soluciones manuales para evitar estos problemas:
    Incorporar el número de versión a las DLL para evitar sobrescribirlas con versiones incompatibles.
    Fijar el comportamiento y no permitir modificaciones en el mismo: De esta forma se evitaría la existencia de DLLs no compatibles.
    Se han planteado dos soluciones por MS:
    Scripts de instalación MSI: se trata de pequeñas bases de datos que indican qué ficheros y versiones instala una aplicación. De esta forma es posible determinar qué versiones son compatibles y cuales no, o volver a instalar versiones en el caso de instalaciones corruptas.
    Ensamblados: Es un concepto que aparece con .NET y consiste en un fragmento de código ejecutable (DLL o EXE) junto a un fichero (que puede estar incorporado como recurso en el fichero) que indica qué contiene, versiones... De esta forma, es posible instalar varias versiones diferentes del mismo ensamblado y cargar la que necesita cada programa usando esa información.
    Ejemplo:
    El ejemplo aquí narrado es un caso de la vida real, sucedio que al tener instalado office 2007 en una un ordenador con Windows XP SP3, donde anteriormente existio office 2003.
    Al intentar instalar Office 2010, el OS solicito desinstalar todas las versiones previas de office, se realizo la desintalacion pero persistían los conflictos, porque habían 2 dll que tenían una versión no reconocida por el framework que implementa office2010, el problema se solucióno borrándolas completamente desde la carpeta installer. Sin embargo MS por ningún lugar recomendó la solución. Queda claro entonces la gran problemática que puede ocasionar el manejo de DLLs dentro de Windows, en especial al hacer upgrade y/o downgrade de software.
    Nelson Mauricio Navarro Canales,SMIS044008.A

    ResponderEliminar
  12. Carlos Ochoa SMIS086110

    Al código duro o codificación dura, (hardcode/el hardcoding) refiere a la práctica del desarrollo del software de encajar datos de la entrada o de la configuración directamente en código de fuente de programas o el otro objeto ejecutable, o formato fijo de los datos, en vez de obtener esos datos de fuentes externas o de generar datos o de ajustar a formato en el programa sí mismo con la entrada dada.

    Considerado como anti-patrón, la codificación dura requiere el código de fuente del programa ser cambiada cualquier momento los datos de entrada o el formato deseado cambia, cuando puede ser que sea más conveniente al usuario final cambiar el detalle por algunos medios fuera del programa.

    ResponderEliminar
  13. Poltergeist

    Son objetos cuyo propósito es llamar métodos de otras clases (creación de clases innecesarias), generando redundancia y consumiendo recursos que son necesarios para ejecutar otros métodos, se le llama poltergeist por que así como aparecen así se van, se puede evitar creando los métodos en las clases donde se utilizan.


    Ejemplo.
    La mayoría de poltergeist están declarados con las palabras ¨Manager¨, ¨Controller¨.

    Una clase Inventario con el método generar(), asociado con las clases Compra y Venta, una clase InventarioManager, esta ultima es una clase poltergeist ya que es una clase innecesaria y el método debe ser declarado únicamente en la clase donde se ejecuta.


    Gisela Yasmin Garcia Espinoza

    ResponderEliminar
  14. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  15. Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que añade modificación alguna.

    Ejemplo:
    La clase Carro es instanciada por la SubClase_Persona esta llama el metodo avanzar de la Clase carro este no Avanza se apaga para el caso esta no supera test de la subclase vacía.

    ResponderEliminar
  16. Antipatrón de diseño

    Un antipatrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema.

    Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.

    El término se origina inspirado en el libro Design Patterns, escrito por un grupo de autores conocido como Gang of Four, y que aglutina un conjunto de buenas soluciones de programación. Los autores bautizaron dichas soluciones con el nombre de "patrones de diseño" por analogía con el mismo término, usado en arquitectura. El libro Anti-Patterns (de William Brown, Raphael Malveau, Skip McCormick y Tom Mowbray, junto con la más reciente incorporación de Scott Thomas) describe los antipatrones como la contrapartida natural al estudio de los patrones de diseño. El estudio formal de errores que se repiten permite reconocer y reconducir los elementos involucrados hacia una mejor solución. Los antipatrones no se mencionan en el libro original de Design Patterns, puesto que éste es anterior.

    Los antipatrones se consideran una parte importante de una buena práctica de programación. Es decir, un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible, dentro del ciclo de vida del software.

    El concepto de antipatrón se puede aplicar a la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.

    Gestión de la configuración:

    Se denomina Gestión de la Configuración al conjunto de procesos destinados a asegurar la validez de todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema de Información (S.I.), a través del estricto control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en el citado desarrollo. Estos dos elementos (control de cambios y control de versiones de todos los elementos del S.I.) facilitan también el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en cada etapa del desarrollo. La gestión de la configuración se realiza durante todas las fases del desarrollo de un sistema de información, incluyendo el mantenimiento y control de cambios, una vez realizada la puesta en producción.

    Infierno JAR (JAR hell):
    Problemas con diferentes versiones o ubicaciones de ficheros JAR (Java), típicamente causados por la falta de comprensión del modelo de carga de clases.

    Ejemplo:
    Que los ficheros esten en diferente ubicacion y esto vendria a ser la causante de el problema.

    David Antonio Bustillo Fuentes......smis037208

    ResponderEliminar
  17. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  18. El antipatrón es una forma para capturar la experiencia de los desarrolladores para poder ser asimilada más fácilmente por otros desarrolladores.

    Los antipatrones capturan las experiencias que repetidamente han arruinado el desarrollo de los proyectos de software y ofrecen sugerencias de solución a estas situaciones.
    La idea que sobre la que descansan los antipatrones es la creencia de que es más fácil detectar lo que se hace mal que proveer un buen comportamiento.

    Nomenclatura heroica (heroic naming:
    Identificar los miembros de un programa(interfaces, clases, propiedades, métodos...)con nombres que provocan que el conjunto aparente estandarización con la ingeniería del software pero que en realidad oculta una implementación anárquica.

    Ejemplo:
    Lo que hacen es que en un programa te hacen pensar que por medio del nombre de los diferentes componentes de dicho programa (interfaces, clases, propiedades, métodos) estos estan estandarizados por medio de la ingeniería de software, pero al final tienen su dominio.

    Franklin Abel Martínez Vigil smis049408

    ResponderEliminar
  19. El antipatron invercion de abstraccion:

    este patron en si es un implementacion del programador, se trata de que un programador oculta procesos que estan en el codigo(el usuario no hace uso de ese proceso) esto no quiere decir que eso proceso este mal codificado, lo que pasa es que el programador decidio no usarlo o ponerlo en la interfas
    ejemplo:
    un sistemas de registro de usuarios tiene en su codigo fuente el boton comprobar registro pero en la interfas de usuario no aparece este boton, ose el antipatron invesion de abstraccion lo que hace es ocultar parte del esquema del sistema.

    Zimri Abisaias Cruz Alvarenga smis061208

    ResponderEliminar
  20. Comprobación de tipo en lugar de interfaz:

    Definición: Este antipatron nos da la pauta para saber si las propiedades y metodos de dos clases tengan relacion con la clase abstracta.

    Ejemplo: Tenemos dos clases: materia y la otra alumno, en estas dos clases no tienen ninguna propiedad y ningun metodo similares.

    Cesar Geovanny Portillo Coreas

    ResponderEliminar
  21. El Antipatron Ancla de Barco (Boat Anchor)
    Un ancla de barco es una pieza de software o hardware que no sirve a ningún propósito útil en el proyecto actual. Muy seguido el ancla del barco es una adquisición costosa lo que hace que la compra aún más inutil.

    Las consecuencias para los administradores y desarrolladores de software son un esfuerzo importante que puede tener que ser dedicados a hacer que el producto funcione.

    Después de una importante inversión de tiempo y recursos, el personal técnico se da cuenta de que el producto es inútil en el contexto actual, y lo abandona por otro enfoque técnico

    EJEMPLO:

    una relación política o programática puede requerir la compra y el uso de una determinada pieza de hardware o software. Este es un supuesto de partida (o restricción) del proyecto de software. Otra razón de peso es cuando un gerente está convencido de la utilidad de la adquisición.

    POR: ERICK ARTURO MARTINEZ NAVARRO

    ResponderEliminar
  22. Entrada chapuza (input kludge).
    No especificar e implementar el manejo de entradas inválidas. En otras palabras el hecho de que un software no contenga un validacion de entrada en datos o una forma de identificar datos no validos.

    Ejemplo:
    en sistema bancario se deben manejar procesos de control de usuario, determinando que tipo de usuario es(adminitrador, cajero, vigilinta,etc), el no verificar que tipo de usuario es el que accede al sistema provocaria que este entre al sistema como administrador y pueda realizar todos los cambios que quiera y hasta dañar el mismo sistema y la BD.

    ALEXANDER DE JESUS ARGUETA SMIS025408
    GRUPO "A" INGENIERIA EN SISTEMAS Y REDES INFORMATICAS

    ResponderEliminar
  23. Antipatron carrera de obstáculos.

    Definición: La incapacidad de no poder determinar las validaciones necesarias para de un sistema lo que con lleva es que el sistema produzca un error en su base de datos.
    Ejemplo. Cuando se está diseñando un sistema se tiene que validar los campos para que cuando sea ejecutado no vaya a tener problemas al momento que el usuario ingrese registros y si olvida agregar un campo el sistema enviara un mensaje que dirá que olvido agregar un campo obligatorio.

    Fatima Amaya

    ResponderEliminar
  24. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  25. Fallo de caché (caching failure): Olvidar restablecer una marca de error cuando éste ya ha sido tratado.
    ERIKA ARGENTINA RIVERA DE LUNA SMIS002608

    ResponderEliminar
  26. ERIKA YAMILETH MARQUEZ SMIS008108
    Accion a Distancia.
    Se basa en la sobrecarga de componentes distantes dentro de un mismo sistema, es decir que tratemos de llevar una lógica o metodología a la hora de realizar acciones sobre componentes alejados del mismo ámbito.
    Ejemplo:
    Solucionar problemas de Proxy que filtre el contenido de el así también este patrón se basa en el modelo vista controlador para forzar a elementos de la vista a realizar un sobreactualizacion.

    ResponderEliminar
  27. Héctor Alexander Velázquez Yanes SMIS002508
    Packratting: consume memoria innecesariamente por que los archivos que se utilizaron tan solamente una vez no se limpian y se van rezagando archivos innecesarios en el sistema .
    Un ejemplo seria cuando se instalan archivos en los cuales no se limpian los archivos temporales y se van acumulando al punto de tener espacio innecesario acumulado en el disco duro o hay sobrecargo en el sistema.

    ResponderEliminar
  28. Danny Stanley Ascencio Pineda SMIS005407

    GRAN BOLA DE LODO

    Este Antipatron se aplica hacia aquellos sistemas los cuales se hacen a veces sin ningun planeamiento previo es decir que se van codificando al principio solo para sastifascer necesidades primordiales y poco a poco se van programando los otros pedazos de codigo para rellenar los vacios e ir llenando con parches el sistema por lo general estos sistemas crecen con el tiempo por el mismo motivo que no se tiene una idea concreta de lo que se quiere un ejemplo de este podrian ser bases de datos las cuales estan como temporales o tamnbien sistemas los cuales se hacen por principiantes o con personas muy pocas organizadas este antipatron fue publicado y popularizado en 1999 por Brian Foote y Joseph Yoder.

    ResponderEliminar
  29. En la ingeniería y la informática, un sistema de compartimentos estancos es un sistema que es un conjunto de elementos interrelacionados que están tan estrechamente unidas entre sí que los elementos individuales no pueden ser diferenciadas, se actualiza o refactorizar. El sistema de copa se debe mantener hasta que pueda ser totalmente sustituido por un nuevo sistema. Por lo tanto, con el tiempo un sistema de compartimentos estancos típicamente también se convierte en un sistema heredado. Este anti-patron demuestra la fragilidad de los softwares

    El codigo de este sistema se ha perdido

    Los sistemas que se construyeron de metodologias de ingenieria ya no se han encontrado


    Por: Juan Jose Coreas Saravia

    ResponderEliminar
  30. Re-dependencia (re-coupling): Introducir dependencias innecesarias entre objetos.

    KARLA COLINDRES SMIS009108

    ResponderEliminar
  31. Antipatrón Lógica super-booleana

    Este antipatrón que recae en la categoría de programación.

    Consiste en utilizar demasiadas estructuras booleanas, que en la creación de un sistema resultan ser innecesarias muchas veces y pueden provocar que el sistema se vuelva muy pesado lo que trae como consecuencia una respuesta más lenta de parte del sistema. Es decir que cuando este antipatrón tiene presencia en un sistema solo demuestra que está mal estructurado.

    Ejemplo:
    Cuando un desarrollador está programando un formulario que cuenta con 20 campos a llenar de los cuales 15 son obligatorios. Utiliza el botón de “Guardar” para validar todos los campos, en el cual toda la estructura del código esta realizada con una estructura booleana para cada campo (dentro de una estructura booleana se encuentran las demás).

    Roberto René Romero Reyes.

    ResponderEliminar
  32. Antipatron Ocultación de Errores
    Definición: Utilizado por los programadores en un sistema o programa para ocultar un error que no han podido o no han querido resolver cuando el usuario comete dicho error lo que hace este antipatron es capturar el error y antes de que se muestre al usuario lo reemplazo por un mensaje sin importancia ocultando así la complejidad de dicho error.
    Ejemplo: Un programador realiza un programa de matemática con las cuatro operaciones básicas suma, resta, multiplicación, división. El programador se equivoco en el orden de las operaciones donde iva suma coloco multiplicación lo que hizo el programador en vez de cambiar el orden de las operaciones fue que cuando el usuario diera clic en la operación suma le tirara un mensaje de error ocultando la complejidad de dicho error.

    Nidia Marbeli Torres Sanchez

    ResponderEliminar
  33. Codigo Duro (Hard-coded): este término dentro de la informática nos muestra una mala práctica hacia en software que consiste en incrustar datos directamente en el código fuente del programa, en lugar de obtener los datos de una fuente externa como un fichero de configuración o parámetros de la línea de comandos, o un archivo de recursos.
    Es considerado como un antipatron de diseño, se trata de una práctica por abandonar, ya que requiere la modificación del código fuente cada vez que cambian datos, cuando lo conviene sería que el usuario final pudiera cambiar estos detalles fuera del código fuente del programa.
    Por lo demás, esta práctica es especialmente problemática si se preparar el software para la traducción a terceros idiomas.
    Un ejemplo para hacer referencia a hard-coded a in fichero tendría escrito el nombre y la ruta del fichero en un lugar específico del disco. Si la localización del fichero cambia, el programador ha de cambiar el código fuente para que apunte a la nueva localización. Una buena práctica seria tener una variable interna llamada <>, que podría ser asignada mediante una ventana de dialogo de navegación de ficheros, de esta manera no sería necesario cambiar el programa por un cambio en los datos.
    La práctica de Hard-code está muy extendida entre programadores noveles, básicamente debido a su poco conocimiento de los estándares de programación, aunque también puede darse en programadores de experiencia contrastada; en este caso algunos autores consideran que se trata de un síntoma de agotamiento que puede llevar al programador a abandonar practicas correctas en favor de otras más rápidas, aun sabiendo que son incorrectas.

    Yeli Raquel Medrano Hernández
    SMIS010008

    ResponderEliminar
  34. • Gas Factory
    El anti patrón fábrica de combustible se dice que es una mala práctica porque este se refiriere a los diseños o implementaciones que son demasiado complejos para todos los requisitos de los que se compone un diseño. Este término se refiere a las refinerías de petróleo, donde la complejidad es también un problema

    Alumno: victor manuel arias marenco

    ResponderEliminar
  35. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  36. Complejidad no Indispensable.
    Este antipatrón de diseño describe la situación a la que se llega cuando estamos en el proceso del desarrollo de una aplicación y tomamos un camino con mayor complejidad a la que realmente es indispensable y en algunos casos esta complejidad no va de acorde con el problema, además que en algunos casos dicha complejidad se introduce por falta de conocimiento o por problemas de planificación.
    Esta situación si no se reconoce fácilmente puede hacer cancelar un proyecto ya que muchas veces la complejidad innecesaria viene a despreciar las soluciones más directas por considerarlas demasiada obvias.

    Ejemplo:Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
    Cabe destacar que fuera de este entorno, lo único "visible" es el método Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privados.

    Jorge Alfredo Molina Castellon--SMIS063610

    ResponderEliminar
  37. Antipatron del yo-yo:
    Definición: Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación.

    Xenia Esmeralda López Mejía

    ResponderEliminar
  38. Antipatron acoplamiento secuencial

    definiciom: es contruir una clase en donde todos sus metodos se llamaran por un orden determinado lo que nos quiere decir que sera exacto en la invocacion de todos sus metodos ya que es necesario que sus metodos se llamen de esta manera en su preciso momento en que se necesiten.

    el ejemplo de como se utilizaría este antipatron que como sabemos es una forma no adecuada para usar ya que crea mas problemas.

    tenemos una clase Calculadora y esta clase tiene tres método los cuales son restar, sumar y dividir ahora queremos utilizar el método dividir pero para utilizarlo se llamaran todos los métodos de la clase en una forma ordenada primero el método restar, después sumar, y por ultimo dividir lo que quiere decir que el proceso es mas largo y hará mas lenta la ejecución des sistema.

    POR: Claudia Lorena Gómez Alvarez
    Grupo: "B" Ing. de SoftwareII

    ResponderEliminar
  39. Antipatron base de datos como comunicador de procesos:
    En este anti patrón se obtiene como resultado un rendimiento pobre de trabajo, al utilizado para describir el uso inadecuado de una base de datos en donde se transmita toda la información y así pueda haber una comunicación entre procesos.
    Ejemplo: El patrón singleton asegura que exista sólo una instancia de
    Una determinada clase.

    jackeline claribel guerrero hernandez smis031108

    ResponderEliminar
  40. El término DLL Hell (infierno de las DLL) se refiere a los problemas ocasionados por las DLL (bibliotecas de enlace dinámico).

    Estas bibliotecas consisten en un conjunto de código común que puede estar compartido entre varias aplicaciones. En Windows estas bibliotecas están muy extendidas y son compartidas por múltiples aplicaciones (por ejemplo, la MFC está compartida por prácticamente todas las aplicaciones gráficas). De esta compartición de código surgen dos problemas que constituyen el "infierno":

    Al instalar un programa se reemplaza una DLL por otra versión incompatible (conflicto de versiones)
    Al desinstalar un programa se borra una DLL compartida
    En ambos casos los programas que compartan la DLL dejarán de funcionar con los consiguientes trastornos que supone.

    Juver Osmin Ramos Ramos

    ResponderEliminar
  41. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  42. Nombre:Silvia Elizabeth Romero Coreas
    Codigo: SMIS008208
    Grupo: "B"

    Botón mágico (magic pushbutton). desarrolla interfaces, a programar la lógica de negocio en los métodos de interacción, implementando los resultados de las acciones del usuario en términos no suficientemente abstractos. Muy común en entorno de programación gráficos. Una manera mejor de hacer esto está en refactorizar la lógica del negocio en una clase o método separado.

    Los problemas con este antipatrón son:
    - Mantenimiento del código difícil.
    - Cambiar la interfaz o la adición de una nueva es complicado.
    - La prueba del código es difícil.

    Ejemplo:
    - visual fox
    - C#
    - Visual studios

    ResponderEliminar
  43. Antipatron: “Problema del Circulo Elipse”

    (conocido a veces como problema del cuadrado-rectángulo) ilustra un número de trampas que puedan presentarse al usar polimorfismo del subtipo en el modelar del objeto. Las ediciones se encuentran lo más comúnmente posible al usar programación orientada al objeto.
    El problema se refiere a qué subtyping/herencia la relación debe existir en medio clases cuál representa círculos y elipses. Más generalmente, el problema ilustra las dificultades que pueden ocurrir cuando una clase baja contiene métodos qué mutate un objeto de una forma que pudo invalidar un invariante (más fuerte) de a encontrado en una clase derivada, el causar Principio de la substitución de Liskov ser violado.
    La existencia del problema de la círculo-elipse se utiliza a veces para criticar la programación orientada al objeto. Puede también implicar que los taxonomies jerárquicos son difíciles de hacer el universal, implicando que los sistemas de clasificación circunstanciales pueden ser más prácticos.

    Alumno: Edgard López
    Código: SMIS 048808
    Grupo : “B”

    ResponderEliminar
  44. ANTIPATRONES DE PROGRAMACIÓN


    MOMENTO DEL CÓDIGO (CODE MOMENTUM) : Establece demasiadas restricciones sobre una parte del sistema debido a la asunción de muchas de sus propiedades desde otros lugares del propio sistema.es donde podemos determinar los privilegios y restricciones que tiene cada usuario de un sistema.

    EJEMPLO: podría ser el sistema de una banco, donde por seguridad se les entrega a sus empleados una contraseña para acceder al sistema, ejemplo un cajero que el encargo de recibir depósitos, transacciones, pago de energía eléctrica, teléfono depósitos en su cuenta, entrega de remesas,etc determinando a cada uno de los empleados ; las restricciones necesarias dependiendo el cargo que el empleado desempeña en dicha empresa, si este quiere acceder a alguna parte del sistema para la cual no tiene permiso este no le permitirá acceder a realizar dicha acción.

    Glenda Berenice Vigil Romero smis000908

    ResponderEliminar
  45. Paola velasquez


    Lava Flow
    En computación, el antipatrón de diseño lava flow o lava seca ocurre cuando un software es entregado antes de ser completado o antes de ser completamente probado y al ser expuesto, ya no es posible cambiar sus características, como cuando un flujo de lava se seca por fuera.
    Al ser utilizado por usuarios o a partir de otros componentes, el margen de posibilidades para realizar modificaciones posteriores a su entrega es muy reducido. Si se encuentran debilidades en el diseño o en la realización, pero que permiten de todas formas su utilización, éstas probablemente no podrán ser corregidas, dado que los usuarios o las aplicaciones que utilizan el software ya se han adaptado a sus características.
    Sólo se puede evitar este patrón fijando un alto nivel de calidad o pruebas en el software como paso previo a su distribución.

    Lava seca (lava flow): Entregar un componente de software antes de estar completo o completamente probado, de manera que la situación derive en el mantenimiento de sus características, buenas o malas (que tienden a quedarse fijas, como un río de lava que se seca por fuera).

    ResponderEliminar
  46. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  47. (anemic domain model):
    El síntoma básico de un modelo de dominio anémicos es que a primera vista parece que la cosa es real. Hay objetos, muchos nombres de los sustantivos en el espacio de dominio, y estos objetos están relacionados con las relaciones ricas y la estructura que los modelos tienen cierto dominio. La captura se produce cuando nos fijamos en el comportamiento, y te das cuenta de que casi no hay comportamiento de estos objetos, haciéndolos poco más que bolsas de captadores y definidores.
    utilizado exactamente solo para casos de produccion...
    Ejemplo:
    el modelo de dominio conjunto no tiene ningún tipo de comportamiento como la adición de un producto a un Carrito de la compra, este entra dentro del carrito pero asta ai no tiene un comportamiento espesifico(no tiene poder de validar).

    Endy Salador Fuentes

    ResponderEliminar
  48. SMIS038308 Brenda Vanessa Manzano

    Refiriéndose a la adicción al patrón Singleton. Este término aparece en la motivación del Singleton, cuyo objetivo es remover los Singletons innecesarios en una aplicación. Dado que el Singleton es quizás el patrón más sencillo del GoF a veces es sobreutilizado y muchas veces en forma incorrecta.


    El principal problema con el uso de este patrón es el mismo que con el uso de variables globales en aplicaciones procedurales. Al mantener un estado global, el singleton se convierte en un foco de posibles errores, principalmente en entornos multi-hilo. La mayoría de los singleton de una aplicación deberían estar implementados de forma que no mantengan ningún estado.

    ResponderEliminar
  49. LLAMAR A SUPER (Callsuper)
    Es un anti patrón Orientado a Objetos el cual consiste en: obligar a las subclases (hijas) a llamar un método de la superclase (padre) que previamente ha sido sobrescrito.
    Obliga a las subclases a llamar a la clase de la que heredan...

    Ejemplo: Tenemos una clase Celular (superclase), dos clases mas, celularNokia y celularMotorola(hijas); la super clase tiene un método que se llama llamar(),y utilizando este anti patrón las clases hijas estarían obligadas a sobrescribir el método llamar()...

    MARICELA BECSLAY HERNANDEZ GUEVARA.
    GRUPO "B",

    ResponderEliminar
  50. SMIS026708 Noe Salomon Castro Majano


    Una Gran bola de lodo es una selva de código enrevesado, chapucero, caóticamente estructurado, que crece descontroladamente, que se mantiene como unido a base de cuerda y cinta aislante. Este tipo de sistemas presentan signos inconfundibles de crecimiento incontrolado y constantes necesidades de reparación. Elementos lejanos en el sistema comparten información profusamente, incluso hasta el punto de que prácticamente cualquier información importante se trata de manera global o se duplica. La estructura global del sistema puede no haber llegado a estar claramente definida nunca. Si alguna vez lo estuvo, es probable que se haya deteriorado hasta el punto de ser imposible reconocerla. Los programadores con un mínimo respeto por la estructuración huyen de esta clase de cenagales. Sólo a aquéllos a los que la arquitectura les trae sin cuidado y que tal vez se sienten cómodos programando por inercia parches día tras día para los interminables agujeros de estos diques que hacen aguas por todas partes, no les importa trabajar en tales condiciones.

    ResponderEliminar
  51. Código espagueti es un término peyorativo para el código fuente que tiene una estructura compleja y enredado el control especialmente uno con muchos GOTOs excepciones hilos o otras ramificaciones "no estructurada" construye. Es tal el nombre porque el flujo de programa tiende a parecerse a un plato de espaguetis, es decir retorcido y enredado.Código espagueti puede ser causada por varios factores incluyendo los programadores inexpertos y un programa complejo que ha sido modificado continuamente durante un largo ciclo de vida.Programación estructurada había disminuido enormemente la incidencia de código espagueti. smis033408 Lorena Lissette parada valladares

    ResponderEliminar
  52. Alumna: Eymi Carolina Zavala Hernandez smis005208

    Anti Patrones
    Sabemos que los patrones son plantillas reutilizables que podemos usar para solucionar problemas habituales en el proceso de desarrollo de software. Así, permiten utilizar soluciones fiables y bien conocidas a problemas concretos, aprovechando experiencias previas como base para la consecución de mejores resultados en los nuevos desarrollos.

    Pues bien, justo en el lado opuesto se encuentran los anti patrones, que definen situaciones y comportamientos que, según experiencias anteriores, nos conducen al fracaso en proyectos de desarrollo de software, es decir, son soluciones o planteamientos que se han demostrado incorrectos.



    Al igual que en los patrones, su descripción está relativamente formalizada y suele recoger los siguientes aspectos:
    • nombre del anti patrón, así como su "alias"
    • su tipología: organizacional, de análisis, desarrollo
    • descripción del problema concreto
    • síntomas, y consecuencias de la aplicación del anti patrón
    • causas típicas y raíces del problema
    • refactorización a aplicar, es decir, una descripción de cómo podríamos replantear el problema y conseguir una solución positiva.
    • ejemplos y escenarios para su comprensión.
    • soluciones relacionadas con la propuesta.

    En este apartado se dará una definición y un ejemplo de uno de ellos.
    Anti patrón Números Mágicos.
    Definición.
    Números mágicos : Incluir en los algoritmos números concretos sin explicación aparente
    Un contenedor mágico es un anti patrón de desarrollo que surge cuando, por inexperiencia, se crean métodos (o funciones) que sirven a una gran cantidad de propósitos afines. Este anti patrón se hace evidente cuando se advierten métodos que reciben una enorme cantidad de parámetros muchos de ellos opcionales, de tipos muy generales, arrays o listas y, muchas veces, retornan también mas de un valor mediante los parámetros pasados por referencia (punteros en C/C++, parámetros out en c#).
    La motivación de quien codifica este código radica en el afán de maximizar el rehusó de una rutina mediante una generalización excesiva. Esto lo lleva a intentar la panacea de lograr la función que "sirve para todo".

    Ejemplo.
    Un ejemplo común se ve con frecuencia en los cursos de programación universitarios en los que los alumnos crean sus funciones "LlenarGrilla(....)" las cuales les permiten completar grillas (controles visuales) de muchas formas diferentes, ordenadas según ciertas columnas, con filas coloreadas según algunas condiciones, con formatos por columnas, ancho por columnas, con bordes o sin ellos, editables o no, etc. Para lograr esto, una función "LlenarGrilla(....)" debe recibir un número significativo de parámetros, muchos opcional, muchos arrays de objetos, algunos booleanos, otros strings y así según las funcionalidades que los alumnos deseen.
    El código final resulta en extremo complejo y difícil de mantener. Cuando surge un nuevo requerimiento, que la función no contempla, solo queda agregar más parámetros a su firma e intentar introducir la nueva característica. Este proceso se repite hasta que se vuelve inviable.

    ResponderEliminar
  53. Programación por permutación (programming by permutation):

    Tratar de aproximarse a una solución modificando el código una y otra vez para ver si acaba por funcionar.

    lo que se entiende de este antipatron es:
    en este antipatron lo que hace es crear el codigo de el sistema y modificar cuan veces sea posible para poder llegar y comprobar que funciona perfectamente.

    RAMON ELIAS GUTIERREZ BERRIOS SMIS076308

    ResponderEliminar
  54. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  55. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  56. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  57. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  58. Manejo de excepciones inútil (useless exception handling): Introducir condiciones para evitar que se produzcan excepciones en tiempo de ejecución, pero lanzar manualmente una excepción si dicha condición falla.
    Por eso siempre es fundamental manejar correctamente las excepciones dentro de nuestras aplicaciones, así nos será más fácil tener una consistencia de datos y roturas de la aplicación frente al usuario final.

    Codigo: smis029008
    Alumna: Vilma del Carmen Vigil Hernandez
    Grupo: "B"

    ResponderEliminar
  59. Yafl(yet another layer, y otra capa más):Este antipatrón trata en la sobrecarga de capas innecesaria a un programa,ya sea de una libreria, o framework.
    SMIS007108 Rodrigo Alberto Jiménez Castillo. Grupo:"A"

    ResponderEliminar
  60. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  61. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  62. Antipatron Redependencia(re-coupling):

    En terminos generales y especificos es:
    Introducir dependencias innecesarias entre objetos.
    Ejemplo:
    un objeto B depende de un objeto A luego se crea un objeto C que depende de B pero
    se hace una dependencia de A tambien. la dependencia de C para A es innecesaria, solamente
    seria necesaria que dependa de B...


    SMIS013408
    Jorge Ernesto Dominguez Caldeorn

    ResponderEliminar
  63. Anti patrón de programación acumulate and fire: este patrón se traduce como "Acumular y Disparar”, el cual se basa en la creación de variables globales las cuales podrán ser usadas en cualquier parte del sistema por lo cual se debe tener mucho cuidado al momento de declararlas ya que al hacerlo de una forma incorrecta no funcionaran de la forma deseada. Como una medida de corrección frente a este anti patrón se emplear el concepto de encapsulación el cual nos permite crear una clase con ese conjunto de variables y establecer una serie de funciones para consultar o modificar las mismas, y así proteger el conjunto frente a las modificaciones indebidas.
    Jemmy Azucena Márquez

    ResponderEliminar
  64. Franklin Romilio Giron Martinez SMIS100210

    problema del Circulo Elips
    (ellipse circle problem)

    El problema del Circulo Elipse o Rectángulo problema cuadrados, se refiere a el problema que ocurre entre dos clases que tengan una relación de herencia en donde la clase padre contiene métodos que se heredaran a la clase hija, en donde la hija provoca que la clase padre se debilite o pierda valor .

    ResponderEliminar
  65. Antipatron Confianza Ciega (blind faith):

    Antipatrón orientado para el desarrollo de programas, es decir, descuidar la comprobación de los resultados que produce una subrutina convertida en una tarea específica, o bien de la efectividad de un parche o solución a un problema.

    Ejemplo:
    Comunmente sucede el caso que en nuestro ordenador instalamos aplicaciones que no tiene totalmente las actualizaciones para solucionar problemas o la usabilidad de una versión previa de la aplicación que van desde un procesador de texto hasta llegar al sistema operativo, pero es así que este patrón entra en juego y hace hincapié de omitir que todo resultado se ha comprobado. Así también lenguajes de programación como Visual Basic .NET, utilizan el nombre función para referirse a subrutinas que devuelven un valor.
    Es así que con ello logramos que un parche puede ser muy efectivo en la solución de problemas para el desarrollo y ejecución de todo resultado que es producto de una tarea antes pactada.

    Edwin David Portillo Hernández SMIS002408

    ResponderEliminar
  66. YAFL (yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

    ResponderEliminar
  67. Antipatron Poltergeists.
    Estas son clases bastantes breves, que desordenan diseños de software, son complejos, son antipatrones que siempre aparecen y por consecuencia son innecesarios. También entran en el camino del diseño apropiado e innecesariamente desordenan el modelo del objeto.

    Ejemplo
    Tenemos un diseño, una clase universidad, alumnos, materias y otras más, y en la clase universidad hay métodos o código redundante que aparecen intencionalmente y desordenan el modelo del diseño.

    Jose Amilcar Leon Dubon
    smis054008
    Ing de software Grupo B

    ResponderEliminar
  68. Infierno JAR o como se conoce en ingles (JAR hell): Es uno de los antipatrones de gestión de la configuración; debido destinados a asegurar la validez del producto. Su funcionalidad radica en localizar problemas con diferentes versiones o ubicaciones de ficheros JAR, típicamente causados por la falta de comprensión del modelo de carga de clases. Es decir; describe todas las diferentes maneras en que el proceso de carga de clases puede llegar a no trabajar.
    Ejemplos:
    • Un caso es cuando un desarrollador o desplegador de una aplicación Java ha puesto accidentalmente dos versiones diferentes de una biblioteca al sistema. Esto no se considera un error del sistema. El sistema podría cargar clases de una o de la otra biblioteca. Por tanto, un desarrollador que piensa que ha reemplazado una biblioteca con una nueva versión, pero el cual ha simplemente añadido la nueva biblioteca a la lista de bibliotecas disponibles, puede sorprenderse de que la aplicación todavía se comporte como cuando la vieja biblioteca estaba en uso, la cual por supuesto, puede estar correcta.
    • Otra versión del problema ocurre cuando dos bibliotecas (o una biblioteca y la aplicación) requieren versiones diferentes de la misma biblioteca tercera. Sin tomar medidas extraordinarias (las cuales pueden incluso estar o no disponibles, dependiendo de las circunstancias) no hay forma de cargar ambas versiones de la biblioteca tercera.

    Jessica Urquilla

    ResponderEliminar
  69. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  70. Objeto sumidero (object cesspool): Reusar objetos no adecuados realmente para el fin que se persigue.

    SMIS003208
    WILMER ALEXIS GALEAS

    ResponderEliminar
  71. JUAN FRANCISCO BENITEZ FLORES SMIS030908

    ANTIPATRON DE PROGRAMACION ENTRADA FACHADA (Input Kludge)

    Si un programa acepta el ingreso de texto libre por parte del usuario, un algoritmo especial puede manejar mal muchas combinaciones de cadenas de entrada legal e ilegal.

    Ejemplo: si el programa acepta el ingreso de texto libre por parte del usuario, un algoritmo especial puede manejar mal muchas combinaciones de cadenas de entrada legal e ilegal.

    ResponderEliminar

Seguidores