Autofac: Framework para IoC

La Inversión de Dependencia o Inversión de Control son conceptualmente lo mismo, aunque el primero sea el último de los principios SOLID y el segundo sea un patrón de diseño. Ambos ayudan a realizar una arquitectura en donde los objetos estén desacoplados.

Autofac es un framework que nos ayuda a implementar estos dos conceptos implementando internamente el patrón Abstract Factory. Soporta .Net framework 4.5, Silverlight 5, aplicaciones para Windows Store y aplicaciones para Windows Phone 8.

Basta sólo con registrar Tipos e Interfaces para que Autofac instancie la clase concreta correspondiente para ser inyectada en otra.

Para comprender mejor su funcionamiento, nada mejor que un ejemplo:

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

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