Antipatrones de desarrollo de software: Poltergeists

Se trata de clases que juegan roles y responsabilidades limitadas dentro del sistema; por lo tanto, su ciclo de vida efectivo es bastante breve. Polstergeist desordena el diseño del software, creando abstracciones innecesarias; son excesivamente complejas, difíciles de comprender y difíciles de mantener.

Este antipatrón es típico en casos donde los diseñadores están familiarizados con el proceso de modelado, pero son nuevos en definición de diseños orientados a objetos y definición de arquitecturas. En este antipatrón, es posible identificar una o más apariciones de clases "fantasmales" que aparecen brevemente para iniciar alguna acción en otra clase más permanente. Akroyd llama a estas clases: "Gypsy wagons". Tipicamente, dichas clases fueron creadas como clases controller que existen sólo para invocar métodos de otras clases, usualmente, en una secuencia predeterminada. Por lo general son evidentes debido a que sus nombres tienen a menudo el sufijo _manager o _controller.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software: Functional Decomposition

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.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software: Ambiguous Viewpoint

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.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software: Lava Flow

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.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software: Continuous Obsolescence

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.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software: The Blob

También conocido como The God Class.
La película The Blob es una buena analogía para este antipatrón. Si bien hay dos películas, una de 1958 y una remake de 1988, ambas tienen casi el mismo argumento: Una forma de vida extraterrestre con forma de gelatina ataca a la tierra. Cualquier cosa que este alien coma, lo hace crecer. MIentras tanto, los incrédulos terrícolas entran en pánico e ignoran al científico loco que es el único que sabe lo que está pasando. Mucha gente es comida antes de que ellos entren en razón. Eventualmente, the blob se hace tan grande que amenaza con acabar con todo el planeta.
Tal como este alienígena, el antipatrón es conocido por haberse "devorado" enteras arquitecturas orientadas a objetos.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software

Una buena estructura de software es esencial para la extensión y mantenimiento de un sistema. El desarrollo de software es una actividad caótica, por lo tanto, la estructura implementada de un sistema tiende a alejarse de la estructura planificada según la arquitectura, el análisis y el diseño.
El refactoring del software es un enfoque eficaz para mejorar su estructura. La estructura resultante no tiene que se parecida a la estructura originalmente planificada.
Los cambios de estructura debido a que los programadores aprenden limitaciones y enfoques, alteran el contexto de las soluciones codificadas. Cuando es usado apropiadamente, el refactoring es una actividad natural en el proceso de programación.
Por ejemplo, la solución para el Antipatrón Spaghetti Code define un proceso de desarrollo de software que incorpora refactoring. Este es altamente recomendable antes que la optimización de rendimiento. Las optimizaciones, a menudo, implican comprometer la estructura del programa. Idealmente, las optimizaciones afectan a pequeñas partes de un programa.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones

¿Qué es un antipatrón?

Los antipatrones, como su contrapartida, los patrones de diseño, definen la jerga de la industria para aquellos defectos comunes en los procesos e implementaciones dentro de las organizaciones. Un vocabulario de alto nivel simplifica la comunicación entre desarrolladores de software y permite una descripción concisa de conceptos en un alto nivel.
Un antipatrón, es una forma literal que describe comúnmente a una solución brindada a un problema pero que genera decididamente consecuencias negativas. El antipatrón puede ser el resultado de un diseñador o desarrollador, que por falta de conocimiento de una solución mejor, o no tener suficiente conocimiento o experiencia en resolver ciertos tipos de problemas o simplemente haber aplicado perfectamente un buen patrón en el contexto equivocado.

Seguir leyendo el post »

Por Juan Barrionuevo

Refactoring aplicando patrones

Me topé hace poco con un problema que podría decirse que es bastante común.
El problema puede que sea resultado de un mal análisis o simplemente de un momento de cansancio. Del mismo modo, puede ser que la solución final no sea la mejor.
Pero sinceramente me pareció un caso bastante sencillo para mostrar como un modelo puede evolucionar utilizando patrones.
No podría decir a ciencia cierta si utilicé sólo un patrón, porque como hemos visto hasta el momento, los patrones no son soluciones mágicas que sirven para cualquier modelo o que se aplica de una única manera. Sino que más bien son plantillas que hasta pueden mezclarse entre sí para poder llegar a un resultado que nos resulte útil para que sea escalable.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Visitor

Intención del patrón

• Representar una operación a ejecutarse en los elementos de una estructura de objetos. Visitor permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
• La técnica clásica para recuperar información.
• Hacer lo correcto en función del tipo de dos objetos.
• Duplicar el envío.

Ejemplo de problema

Muchas operaciones distintas y sin relación necesitan ser ejecutadas en una estructura heterogénea de objetos (o nodos). Se desea evitar ensuciar las clases con estas operaciones. Además, no se quiere tener que averiguar el tipo de cada nodo y convertirlo (cast) al tipo correcto antes de ejcutar la operación deseada.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Template method

Intención del patrón

• Define el esqueleto de un algoritmo en una operación, delegando algunos pasos a las clases derivadas del cliente. Template method permite a las subclases redefinir ciertos pasos de un algortimo sin cambiar la estructura del mismo.
• La clase base declara algoritmos "placeholders" y las clases derivadas implementan dichos algoritmos.

Ejemplo de problema

Dos componentes diferentes tienen similitudes significantes, pero no hay una interfaz o implementación común que pueda ser reutilizada. Si un cambio común a ambos componentes resulta necesario, se debe duplicar el esfuerzo en realizar ese cambio.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Strategy

Intención del patrón

• Definir una familia de algoritmos, encapsular cada uno y hacerlos intercambiables. Strategy le permite al algoritmo variar independientemente del cliente que lo usa.
• Captura la abstracción en una interfaz y encapsula la los detalles de la implementación en clases derivadas.

Ejemplo de problema

Una de las estrategias dominantes del diseño orientado a objeto es el principio Open-close.
La figura muestra cómo se logra habitualmente encapsular los detalles de la interfaz en una clase base y enterrar los detalles de la implementación en las clases derivadas. Los clientes pueden entonces acoplarse a una interfaz y no tener que experimentar los trastornos asociados con el cambio. No hay impacto cuando el número de clases derivadas cambia y tampoco lo hay cuando la implementación de una clase derivada cambia.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: State

Intención del patrón

• Permitir a un objeto cambiar su comportamiento cuando cambia su estado interno. El objeto parecerá cambiar su clase.
• Un estado orientado a objetos.
• Un Wrapper + el objeto envuelto por el Wrapper + colaboración.

Ejemplo de problema

El comportamiento de un objeto monolítico y debe cambiar su comportamiento en tiempo de ejecución según su estado. O bien, una aplicación que se caracteriza por tener extensos y numerosos sentencias case que manejan el control de flujo basado en el estado de la aplicación.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Observer

Intención del patrón

• Define una dependencia uno a muchos entre objetos, para que, cuando un objeto cambie su estado, todos sus dependencias sean notificadas y actualizadas automáticamente.
• Encapsula el componente central (o motor o núcleo) en un Subject abstracto y los componentes variables (o interfaz de usuario u opcional) en una jerarquía de Observer.
• Es la parte "View" en Model-View-Controller.

Ejemplo de problema

Un diseño molítico de gran tamaño no se ajusta bien a una nueva representación gráfica o se imponen requerimientos de seguimiento.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Null object

Intención del patrón

Encapsular la ausencia de un objeto mediante la provisión de una alternativa sustituible que ofresca un valor por defecto con comportamiento "No hacer nada". En resumen, un diseño en donde "nada resultará de nada".
Usar el patrón Null object cuando:

• Un objeto requiera de un colaborador. El patrón Null object no introduce esta colaboración; hace que se use una colaboración que ya existía.
• Alguna de las intancias del colaborador no haga nada.
• Se desee abstraer el manejo del "null" fuera del cliente.

Problema de ejemplo

Dado que una referencia a un objeto puede opcionalmente ser nula y que el resultado de la verificación de ser null es no hacer nada o usar algún valor por defecto ¿Cómo puede la ausencia de un objeto (la presencia de una referencia nula) ser tratada de manera transparente?

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Memento

Intención del patrón

Sin violar el encapsulamiento, captura y externaliza el estado interno de un objeto para que el objeto pueda ser devuelto a dicho estado posteriormente.
Una cookie mágica que encapsula un "punto de control".
Proporciona la capacidad de deshacer el estado completo de un objeto.

Ejemplo de problema

Se necesita restaurar un objeto a su estado previo (por ejemplo: operaciones del tipo "deshacer" o "rollback").

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Mediator

Intención del patrón

• Definir un objeto que encapsule como interactúan un conjunto de objetos. Este patrón promueve la pérdida de acoplamiento haciendo que dicho conjunto de objetos no estén referenciados entre ellos explicitamente. Esto permite variar su interacción de manera independiente.
• Diseñar un intermediario que permita desacoplar las parejas.

Ejemplo de problema

Se desea diseñar componentes reusables, pero las dependencias entre las posibles piezas reusables demuestran el fenómeno "código spaghetti".

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Iterator

Intención del patrón

• Proporciona una manera de acceder a los elementos de un objeto contenedor (colección) de manera secuencial sin exponer su representación subyacente.
• La librería estándar de C++ y Java tienen abstracciones que permiten desacoplar las colecciones de los algoritmos.
• Promueve al "estado completo del objeto" del recorrido de una colección.
• Recorrido polimórfico.

Ejemplo de problema

Necesidad de abstraer el recorrido de muy diferentes estructuras de datos para que los algoritmos puedan ser capaces de interactuar con cada una de forma transparente.

Seguir leyendo el post »

Por Juan Barrionuevo

Libro recomendado: Diseño ágil con TDD

Diseño ágil con TDD

Autores: Carlos Blé Jurado, Juan Gutiérrez Plaza, Fran Reyes Perdomo y Gregorio Mena.

Descripción: ¿Dedicas una gran parte de tu tiempo de desarrollo a resolver incidencias de aplicaciones en producción?, ¿te enfrentas a sesiones de depuración interminables para encontrar la raíz de un problema?, ¿te extenúa descubrir innumerables fallos cada vez que introduces nuevas características a funcionalidades ya existentes?. Si respondes afirmativamente estas cuestiones y quieres promover el cambio, en este libro encontrarás la clave.

Comentario: Con un único ejemplo de desarrollo (la vieja y querida calculadora), éste libro explica de manera fácil y amena la metodología de diseño TDD. La ausencia de literatura al respecto de TDD en español, convierte a este libro en una herramienta muy útil para quienes no manejan el idioma inglés.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Interpreter

Intención del patrón

• Dado un lenguaje, define una representación para su gramática junto con un intérprete que usa la representación para interpretar sentencias en el lenguaje.
• Asignar un dominio al lenguaje, el lenguaje a una gramática y la gramática a un diseño orientado a objeto jerárquico.

Ejemplo de problema

Una clase de problemas que ocurre repetidamente en un dominio bien definido y bien entendido. Si el dominio fue caracterizado con un lenguaje, entonces los problemas podrían ser fácilmente resueltos con un motor de "interpretación".

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Command

Intensión del patrón

• Encapsular una solicitud como un objeto, lo que permite parametrizar clientes con diferentes solicitudes, cola o registro de solicitudes, y soportar operaciones que se pueden deshacer.
• Promover la "invocación de un método en un objeto" a ser un objeto "completo".
• Un callback orientado a objeto.

Ejemplo de problema

Se necesita emitir peticiones a los objetos sin saber nada de la operación que se solicita o el receptor de la solicitud.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Chain of Responsability

Intención del patrón

• Evitar el acoplamiento entre el emisor de una solicitud y quien la recibe dando a más de un objeto la posibilidad de atender la solicitud. Encadenamiento de objetos que reciben y pasan las solicitudes a lo largo de la cadena hasta un objeto que la maneja.
• Lanzar y liberar solicitudes con una canalización de procesamiento individual que contiene muchos posibles "manejadores".
• Una lista enlazada orientada a objeto con recursividad transversal.

Ejemplo de problema

Existe un potencialmente variable número de "manejadores", "elementos de procesamiento" o "nodos" y una gran cantidad de peticiones que deben ser manejadas. La necesidad de procesar eficientemente las solicitudes sin relacionar manera dura los manejadores y las precedencias; o mapeos entre la solicitud y el manejador.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Proxy

Intención del patrón

• Proporcionar un sustituto o placeholder para otro objeto para controlar el acceso a él.
• Utilizar un nivel extra de indirección para soportar un acceso distribuido, controlado o inteligente.
• Agregar un wrapper y delegación para proteger el componente real de la complejidad excesiva.

Ejemplo de problema

Se necesita soportar objetos que están ávidos de recursos. A su vez, se requiere que dichos objetos no se instancien a menos que sean requeridos a su vez por un cliente.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Private Class Data

Intención del patrón

• Controlar el acceso de escritura a los atributos de la clase.
• Separar los datos de los métodos que los usan.
• Encapsular la inicialización de datos de la clase.
• Proporcionar la forma de que una vez asignado el valor de un atributo, no vuelva a modificarse.

Ejemplo de problema

Una clase que exponer sus atributos (variables de clase) para ser manipulados. Cuando dicha manipulación ya no es deseada, por ejemplo, tras la ejecución del constructor. El uso del patrón de diseño Private Class Data previene dicha manipulación no deseada.
Una clase puede tener atributos variables que no pueden ser declarados como final. Usando este patrón de diseño permite la asignación por única vez de este tipo de atributos.
La motivación por este patrón de diseño proviene del objetivo de proteger el estado de la clase reduciendo al mínimo la visibilidad de sus atributos.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Flyweight

Intención del patrón

• Comparte para soportar un gran número de objetos de grano fino de manera eficiente.
• La estrategia de GUI Motif de reemplazo de widgets pesados por widgets livianos.

Ejemplo de problema
El diseño de los objetos hasta los niveles más bajos de granularidad del sistema proporciona una óptima flexibilidad, pero puede resultar inapropiadamente costosa en términos de rendimiento y uso de memoria.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Facade

Intención del patrón

• Proveer una interfaz unificada para un conjunto de interfaces en un subsistema. El patrón Facade define una interfaz de alto nivel que hace que el subsistema sea fácil de usar.
• Envolver un subsistema complicado con una interfaz simple.

Ejemplo de problema
Un segmento de la comunidad de clientes necesita una interfaz simplificada para toda la funcionalidad de un subsistema complejo.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Decorator

Intensión del patrón
Agregar responsabilidades adicionales a un objeto dinámicamente. El patrón Decorator proporciona una alternativa más flexible que la herencia para extender funcionalidad.
Embellecimiento específico para el cliente de un objeto Core envolviéndolo recursivamente (Wrapping). Como envolver un regalo y ponerlo en una caja. Y finalmente envolver la caja.

Ejemplo de problema
Se quiere agregar nuevo comportamiento o estado a un objeto individual en tiempo de ejecución. La herencia no es factible debido a que es estática y se aplica a toda una clase.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Composite

Intensión del patrón

• Componer objetos en estructuras de árbol para representar jerarquías totales o parciales. El patrón Composite permite a los clientes tratar objetos individuales y compuestos de manera uniforme.
• Composición recursiva. "Los directorios contienen entradas y cada una de ellas puede ser un directorio".

Ejemplo de problema
Una aplicación necesita manipular una colección jerárquica de objetos "primitivos" y "compuestos". El procesamiento de un objeto primitivo se maneja de una manera y el procesamiento de un objeto compuesto se maneja de otra. El tener que consultar el "tipo" de cada objeto antes de intentar procesarlo, no es deseable.

Seguir leyendo el post »

Por Juan Barrionuevo

Libro recomendado: Clean code

Clean code
A hand book of agile Software Craftmanship

Autor: Robert C. Martin

Descripción: incluso el mal código puede funcionar. Pero si no es claro, puede poner de rodillas a una organización de software. Cada año, incontables horas y recursos significativos se pierden debido a código pobremente escrito. Pero esto no tiene que ser así.

Comentario: Posee numerosas recomendaciones sobre escritura de código para que sea claro de leer y entender por quien lo lee. Porque éste no sólo es escrito, sino también leído, ya sea por uno mismo o por otras personas, es que debe ser escrito de una manera clara y simple.

Por Juan Barrionuevo

Patrones de diseño estructurales: Bridge

Intención del patrón

• Desacoplar una abstracción de su implementación de manera que ambas puedan variar independientemente.
• Publicar la interfaz en una jerarquía de herencias y ocultar la implementación en su propia jerarquía de herencia.
• Además de encapsulación, se usa para aislamiento.

Ejemplo de problema
"El endurecimiento de las arterias del software" ha ocurrido por el uso de subclases de una clase base abstracta para proporcionar implementaciones alternativas. Esto "suelda", en tiempo de compilación, la unión entre la interfaz y la implementación. La abstracción y la implementación no pueden ser extendidas o compuestas de manera independiente.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño estructurales: Adapter

Intención del patrón

• Convertir la interfaz de una clase en otra interfaz que el cliente espera. Adapter permite trabajar a clases de manera conjunta que de otra manera sería imposible por incompatibilidad de interfaces.
• Envolver una clase existente con una nueva interfaz.
• Necesidad de coincidir con la interfaz de un viejo componente con un nuevo sistema.

Ejemplo de problema
Un viejo componente una convincente funcionalidad que invita a reutilizarlo, pero su "visión del mundo" no es compatible con la filosofía y arquitectura del sistema actualmente en desarrollo.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño creacionales: Singleton

Intención del patrón

• Asegura que una clase tiene una única instancia y proveer un punto de acceso global a ella.
• Inicialización "just-in-time" o inicialización "on first use" encapsulada.

Ejemplo de problema
La aplicación necesita una y sólo una instancia de un objeto. Adicionalmente se necesita una inicialización perezosa (lazy initialization) y acceso global.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de creación: Prototype

Intención del patrón

• Especifica los tipos de objetos a crear utilizando una instancia prototipo, y crear nuevos objetos mediante la copia de este prototipo.
• Cooptación de una instancia de una instancia para usarlo como un prototipo de todas las instancias futuras.

Ejemplo de problema
La aplicación especifica de forma dura la clase de objeto que debe crear con cada expresión new.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de creación: Object pool

Intención del patrón
Utilizar un pool (o agrupamiento) de objetos puede ofrecer un significativo aumento de rendimiento. Es más eficaz en situaciones donde el costo de la inicialización de instanciar una clase es alta, el ritmo de instanciación de la misma también es alta, pero el número de instancias en uso en cualquier momento es baja.

Ejemplo de problema

Los agrupamientos de objetos (también conocidos como agrupamientos de recursos) se utilizan para gestionar el caché de objetos. Un cliente con acceso a un agrupamiento de objetos puede evitar crear nuevos objetos simplemente pidiendo al agrupamiento uno que haya sido instanciado antes con anterioridad. En general, la agrupación será cada vez mayor, es decir, el agrupamiento va a crear por sí mismo nuevas instancias si está vacío, o bien, podría tratarse de un pool que restringe la cantidad de objetos creados.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de creación: Factory Method

Intención del patrón

• Definir una interfaz para crear un objeto, pero dejar que las subclases decidan cuál clase instanciar. Factory Method permite a una clase diferir la instanciación a subclases.
• La definición de un constructor "virtual".
• Que el operador new sea considerado dañino.

Ejemplo de problema
Un framework necesita estandarizar el modelo de arquitectura para una variedad de aplicaciones, pero permitirle las aplicaciones definir de manera individual sus propios objetos de dominio y asegurar su instanciación.

Seguir leyendo el post »

Por Juan Barrionuevo

Vacaciones...

Este post es sólo para contarles que el blog (y quien suscribe) ha entrado en modo vacaciones hasta febrero.
Para entonces retomaremos con los patrones de diseño que nos restan para ir mejorando nuestro diseño de aplicaciones.
Hasta entonces y muchas gracias por tu lectura.

Por Juan Barrionuevo

Patrones de diseño de creación: Builder

Intención del patrón

• Separar la construcción de un objeto complejo de su representación para que el mismo proceso de construcción pueda crear diferentes representaciones.
• Procesar una representación compleja y crear uno de los diversos tipos de objeto.

Ejemplo de problema
Una aplicación necesita crear los elementos de un conjunto complejo. La especificación para el conjunto existe en un almacenamiento secundario y una de las representaciones debe ser creada en el almacenamiento primario.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de creación: Abstract Factory

Intención del patrón

• Proveer una interfaz para la creación de familias de objetos, relacionados o dependientes, sin especificar su clase concreta.
• Una jerarquía que encapsula: muchas posibles plataformas y la construcción de una suite de productos.
• Que el operador new sea considerado como perjudicial.

Ejemplo de problema
Si una aplicación está diseñada para ser portátil, ésta necesita encapsular sus dependencias de la plataforma en la que se ejecute. Dichas plataformas podrían incluir: sistema operativo, interfaces de usuario, bases de datos, etc. Muy a menudo, éste encapsulamiento no ha sido diseñado de antemano y un montón de declaraciones del tipo #ifdef con opciones para todas las plataformas soportadas comienzan a reproducirse como conejos a través del código.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño

En la ingeniería de software, un patrón de diseño es una solución genérica y repetitiva aplicable a problemas comunes que ocurren en el diseño de software. Un patrón de diseño no es un diseño definitivo que puede ser transformado en código directamente. Es mas bien una descripción o plantilla que nos indica el cómo resolver el problema y que puede usarse en muchas diferentes situaciones.
Los patrones de diseño pueden acelerar el proceso de desarrollo proporcionando paradigmas comprobados. El diseño eficaz de software requiere considerar cuestiones que pueden no ser visibles hasta después de la implementación.
El uso de patrones de diseño ayuda a prevenir problemas sutiles que pueden causar problemas mayores y mejora la legibilidad del código para los programadores y arquitectos familiarizados con los patrones.
A menudo, la gente sólo comprende la manera de aplicar ciertas técnicas de diseño de software para ciertos problemas. Estas técnicas son difíciles de aplicar a una amplia gama de problemas. Los patrones de diseño proveen soluciones generales, documentadas de una forma que no requieren detalles específicos vinculados a un problema particular.

Seguir leyendo el post »

Por Juan Barrionuevo