Factory Method. Parte I - Introducción

Una norma básica para evitar acoplamiento entre clases concretas y el cliente que las usa es trabajar para la interface y no para la implementación. De eso se trata: no queremos clases concretas en nuestro código.

Tenemos nuestro código, con la lógica de negocio, que utiliza distintas clases que heredan de una interface común, pero, ¿cómo hacemos para no utilizarlas directamente? Esa es la gran incógnita a resolver.

¿Por qué no queremos clases concretas en nuestro código?

Imaginemos los siguientes casos:

• Tenemos código que queremos reutilizar en distintos proyectos ya que la parte central hace algo concreto, pero en cada proyecto, por lo que sea, ese algo concreto se hace de distintas formas. 
•  Queremos que nuestro código central no tenga que ocuparse de cosas que no son su cometido. Dicho de otra forma, tenemos código central que para lograr su fin puede utilizar distintos caminos que no tenemos porqué conocer, queremos que el sistema sea independiente de sus productos.

En ambos casos aprovechamos clases concretas de un mismo tipo. Utilizamos polimorfismo. En estos casos la clase principal no puede saber qué productos debe crear.

Esas clases concretas se pueden seleccionar en un largo condicional dentro del código central, y eso es precisamente lo que queremos evitar. Y además, para el condicional necesitaríamos un parámetro en el código central que no haría falta para nada más.

¿Qué pasa si necesitamos crear una nueva clase concreta? ¿O nos vamos a otro proyecto con clases concretas diferentes?

Habría que modificar el código central, la lógica de negocio. Cualquier programador que meta una clase concreta nueva debería tocar esa parte, y eso no es recomendable. ¿Por qué no sacamos esa creación de clases concretas fuera de la lógica central (fuera del framework)?

Por eso no queremos acoplar la lógica de negocio a la creación de clases concretas.

Queremos que el código central se centre sólo en qué hace, trabajando contra una interface, sin conocer así a las clases concretas, y que la creación de estas esté desacoplada; si añadimos una nueva clase concreta no tendremos que tocar la parte central del código.

¿Cómo creamos entonces esas clases concretas?

Aquí entran en juego distintos patrones de diseño, y en ese caso concreto el Factory Method.

La definición del propósito de este patrón en el libro Design Patterns: Elements of reusable object-oriented software es la siguiente “Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos”.

Aquí acaba está introducción con la necesidad de tener clases que nos ayuden a crear objetos. En sucesivos posts pondré ejemplos concretos del factory method pattern.