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.

The Liskov's Substitution Principle (LSP)

The Liskov's Substitution Principle (LSP)

"Las subclases deben poder sustituirse por sus clases base"

Este post pertenece a la serie Principios SOLID.

En el post "The Open/Close Principle (OCP)" hablamos de que el OCP es la base para crear código mantenible y reutilizable. Además vimos que el concepto clave del OCP era al abstracción. Uno de los principales mecanismos para soportar abstracción en los lenguajes de tipos estáticos como C# es la herencia.

The Single Responsibility Principle (Principio de responsabilidad única)

Single Responsibility Principle (SRP)

"Una clase sólo debe tener una responsabilidad. O lo que es lo mismo, una clase debe tener una y sólo una razón para cambiar". (Robert C. Martin)

Este post pertenece a la serie Principios SOLID.

Realmente este parece un principio simple, sin embargo no hay que dejarse engañar por las apariencias. A lo largo de este post veremos es necesario conocer en profundidad todas las repercusiones de este principio para poder aplicarlo correctamente.

The Open/Close Principle (Principio Abierto/Cerrado)

The Open/Close Principle (OCP)

"Un módulo debe estar abierto para la extensión pero cerrado para la modificación."

Este post pertenece a la serie Principios SOLID.

De todos los principios de diseño este es quizá el más importante. Quiere decir que debemos diseñar nuestros módulos de forma que puedan extenderse sin tener que modificarlos. En otras palabras, tenemos que poder cambiar lo que el módulo hace sin cambiar el código fuente del módulo.

Introducción a los principios de diseño

¿Que son los principios de diseño de software?

Este post pertenece a la serie Principios SOLID.

Los principios de diseño de software son una serie de directrices que nos ayudan a crear buenos diseños de software.