Patrones de creación: Factory Method

Este post corresponde a la serie Patrones de diseño - Patrones de creación

Factory Method

"Define una interfaz para crear un objeto, pero deja que sean las subclases las que deciden que objeto instanciar. Factory Method permite a la clase diferir la instanciación del objeto a las subclases".

En el post sobre Abstract Factory ya vimos, aunque de pasada, el patrón Factory Method. Abstract Factory se centra en crear familias de objetos y cada uno de los objetos de la familia se crean habitualmente mediante Factory Method.

Patrones de creación: Builder

Este post corresponde a la serie Patrones de diseño - Patrones de creación

Builder

"Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción puede crear representaciones distintas"

Como en la mayoría de patrones de diseño entender la definición a primera vista es difícil. Intentaré explicar exactamente qué quiere decir esta definición del patrón Builder.
La idea fundamental es separar la lógica de construcción de los objetos resultantes, de esta forma podemos reutilizar la misma lógica de construcción pero obtener distintos objetos complejos.

Patrones de creación: Abstract Factory

Este post corresponde a la serie Patrones de diseño - Patrones de creación

Abstract Factory

Oficialmente el patrón Abstract Factory: "Provee una interfaz para crear familias de objetos dependientes o relacionados sin conocer sus clases concretas".

Como ya mencioné en el post de introducción de la serie "Patrones de diseño" un patrón es una guía para solucionar un problema. Así que lo primero será definir el problema para el que aplicar este patrón será útil.

Vamos a empezar por analizar la definición del patrón. Lo primero que me pregunto es ¿por qué querríamos crear una familia de objetos? Y después, ¿cómo es posible que no conozca sus clases concretas? Si voy a crear una familia de objetos necesitaré conocer que tipos de objetos voy a crear ¿no? Vamos a aclarar estas dudas planteando el problema que queremos resolver.

Introducción a los patrones de diseño

Realizar diseños orientados a objetos es difícil, y realizar diseños orientados a objetos reutilizables es más difícil aún. Tienes que encontrar los objetos correctos, encapsularlos en clases con la granularidad correcta, definir las interfaces, la herencia y las relaciones entre los objetos.

Una de las cosas que los desarrolladores debemos aprender cuanto antes es que no debemos afrontar la resolución de los problemas siempre desde cero. En lugar de eso debemos buscar soluciones que hayan funcionado a nosotros mismos o a otros en el pasado.

Principios DRY, YAGNI y KISS

En este post vamos a ver otros principios de diseño a tener en cuenta.
Que los ponga todos en el mismo post no quiere decir que sean menos relevantes que los principios explicados hasta el momento.

Inversion of Control

Inversión de control (IoC)

La inversión de control es una técnica de programación mediante la cual se invierte el flujo de ejecución de un programan con respecto a una ejecución tradicional.

En la programación tradicional nuestro código (cliente) llama a métodos de otras clases de las que dependemos, recibe el resultado y vuelve a llamar a otros métodos etc. controlando así el flujo de ejecución del programa. Mediante la Inversión de control, en nuestro código implementamos métodos que son llamados por esas otras clases de las que dependemos en el momento adecuado.

Dependency Injection e IoC Container

Dependency Injection (DI)

"Suministrar a una clase los objetos de los que depende en lugar de que sea la propia clase quien lo cree".

En el anterior post Dependency Inversion Principle hablamos de cómo siempre crear dependencias a clases abstractas e interfaces de un nivel de abstracción igual o superior al de nuestra clase.