Antipatrones de desarrollo de software: Functional Decomposition

0 comentarios
Este antipatrón, es bueno en un entorno de desarrollo procedural. Incluso resulta útil para comprender la naturaleza modular de una aplicación a gran escala.
Desafortunadamente, no se traslada directamente a una jerarquía de clases y aquí es donde comienza el problema.
El antipatrón es el resultado de experimentados desarrolladores, no orientados a objetos, quienes diseñan e implementan una aplicación en un lenguaje orientado a objetos. Cuando los desarrolladores están cómodos con una rutina "principal" que llama a numerosas subrutinas, pueden tener la tendencia de hacer todas subrutinas de una clase, ignorando por completo la jerarquía de clases (y practicamente ignorando por completo la orientación a objetos).
El código resultante se asemeja a un lenguaje estructural como pascal o FORTRAN en la estructura de una clase. Puede ser increíblemente complejo, como inteligentes desarrolladores procedurales idean formas muy inteligentes de replicar sus métodos probados en el tiempo en una arquitectura orientada a objetos.

Antipatrones de desarrollo de software: Ambiguous Viewpoint

0 comentarios

Problema

El análisis y diseño de los modelos orientados a objetos (OOA&D) son a menudo presentados sin poner en claro el punto de vista presentado por el modelo. Por defecto, los modelos OOA&D indican un punto de vista de implementación que es potencialmente, como mínimo, útil. Puntos de vista mezclados no permiten la separación fundamental de las interfaces de los detalles de su implementación, lo cual es uno de los beneficios primarios del paradigma de la orientación a objetos.

Antipatrones de desarrollo de software: Lava Flow

0 comentarios
También conocido como Dead Code, el antipatrón Lava Flow es comúnmente encontrado en sistemas que fueron originalmente una investigación pero terminaron en el producto final. Se caracteriza porque al igual que la lava, "fluye" de las versiones anteriores de desarrollo esparcidos a lo largo del código, el cual ahora se ha endurecido como el basalto, inamovible, generalmente un masa inútil de código de la que nadie puede recordar mucho.
Este es el resultado de los primeros tiempos de desarrollo cuando, mientras se investigaba, los desarrolladores intentaban muchas formas de cumplir con los requerimientos, típicamente en una carrera para algún tipo de demostración, echando al viento las buenas prácticas de diseño y sacrificando la documentación.

Antipatrones de desarrollo de software: Continuous Obsolescence

0 comentarios

El problema

La tecnología cambia tan rápidamente que los desarrolladores tienen problemas para mantener el paso con las versiones actuales de software y encontrar combinaciones de productos que puedan trabajar juntos.
Dado que cada línea comercial de producto evoluciona con cada nuevo release, la situación se vuelve cada vez más difícil a los desarrolladores hacerle frente. Encontrar releases de productos compatibles que interoperen exitosamente, es aun más difícil.
Java es un ejemplo bien conocido de este fenómeno, con nuevas versiones saliendo cada pocos meses. Por ejemplo, en el momento que un libro de java 1.X va a la imprenta, un nuevo Java Develpment Kit hace obsoleta a esa información. Java no es el único, muchas otras tecnologías participan de Continuous Obsolescence.
 
Copyright 2009 Programación SOLIDa
BloggerTheme by BloggerThemes | Design by 9thsphere