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.

Dependency Inversion Principle

Dependency Inversion Principle (DIP)
"Depender de abstracciones. No depender de concreciones."

Este post pertenece a la serie Principios SOLID.

Hay diferentes formas de definir el DIP:

• Las abstracciones no deben depender de los detalles.
• El código debe depender de cosas que estén en su mismo nivel de abstracción o superior
• Las reglas de alto nivel no deben depender de los detalles de bajo nivel
• etc.

Todas ellas se basan en la idea de crear dependencias hacia niveles de abstracción superior.

The Interface Segregation Principle

The Interface Segregation Principle (ISP)
"Un cliente no debe estar obligado a depender de interfaces que no usa"

Este post pertenece a la serie Principios SOLID.

Primero me gustaría aclarar que aunque el nombre de este principio usa la palabra "Interface" se refiere a una interfaz en un sentido amplio de la palabra como cualquier estructura de código que define una parte pública de la clase que la implementa.