Factory Pattern en PHP

Importante: No confundir el Factory Pattern con el patrón Abstract Factory, aunque del mismo tipo, resuelven distintos problemas de distinta forma.

A considerar…

El patrón de diseño Factory viene a solucionar los inconvenientes con la creación o instanciación de nuestros objetos. La idea es encapsular u ocultar al cliente los detalles internos para la creación de ciertos objetos, o dicho de una mejor manera:

Desacoplar la lógica de creación de la lógica de negocio, evitando al cliente conocer detalles de la instanciación de los objetos de los que depende.

Propósito del patrón

Implementación del Factory Pattern

Caso de ejemplo

Supongamos que necesitamos desarrollar un sistema para una tienda apple el cual permita mostrar la ficha informativa de cada ordenador fabricado por Apple. Una primera aproximación del código sería:

Como se puede observar, esta implementación contiene evidentes problemas y el principal es el uso del switch case encargado de gestionar el modelo a mostrar.

Ya que si a futuro necesitamos añadir nuevos modelos, habra que estar editando el switch para añadirlos por lo que esta implementación no es limpia pero si dependiente de muchísimo mantenimiento.

Ademas de que visto de otra forma, estaríamos rompiendo el principio de responsabilidad única (Single Responsability Principle) de SOLID puesto que una misma clase esta gestionando lo que debería estar separado en varias clases, en nuestro ejemplo, una clase por modelo.

Implementando Factory Pattern

Los pasos a seguir para implementar en este caso el patrón Factory son:

  • Encapsular en objetos la información relativa a cada modelo de ordenador. No tiene sentido el tener esas constantes y variables dentro del switch.
  • En pro de estandarizar las acciones a realizar, crear una interfaz que todos los objetos implementen. Debido a que los rubros de información a mostrar son iguales, es preferible que todos implementen una misma interfaz que le indique a cada clase qué métodos debe definir.
  • Extraer la lógica de creación a una factoría. El cliente (la ficha técnica en este caso) no tiene por qué conocer cómo se instancian estos objetos, no es su responsabilidad, y además no es reutilizable. Saquemos ese código a una clase nueva.
  • Usar la factoría en la ficha técnica. Hagamos uso de la factoría en el cliente.

ModelFactory Class

TechnicalSheetInterface Interface

TechnicalSheet Class

Macbook Class

MacbookAir Class

Macbook Pro Class

IMac Class

Resumamos un poco lo implementado

  • Definimos la interfaz TechnicalSheetInterface, que permite definir los getters necesarios para generar la información técnica de cada modelo.
  • Se ha creado una clase por cada uno de los modelos de ordenadores disponibles.
  • Hemos creado una clase ModelFactory que se encarga de construir el modelo según el código que se envíe y de lanzar una excepción en caso de no existir el modelo que se intenta mostrar.
  • El cliente TechnicalSheet ahora recibe en el constructor la factoría y hace uso de ella para obtener un objeto que implementa TechnicalSheetInterface con el que muestra la ficha técnica correspondiente.

Ventajas del Factory Pattern

  • La factoría es altamente reutilizable, solo hay que pasarla como dependencia.
  • El testing del cliente es mucho más sencillo, podemos usar mocks para la factoría y simular cualquier tipo de repuesta por parte de la misma, permitiendo testear todos los casos de uso posibles.
  • Si queremos añadir un nuevo modelo, solo hay que editar la factoría y añadirlo ahí, pasará a estar disponible para todos los usuarios de la factoría sin tener que replicar código.

Contras del Factory Pattern

  • En este ejemplo, si la cantidad de opciones crece en exceso, la factoría puede llegar a ser una clase difícil de mantener y habría que encontrar otras alternativas al switch como por ejemplo utilizar la clase ReflectionClass de PHP para instanciar la clase correspondiente basado en el nombre del modelo de ordenador a mostrar.

Consideraciones finales

Abstraer al cliente de la creación de los objetos de los que depende es un principio básico en la creación de software de calidad. Esto nos permite cumplir con dos principios SOLID de un plumazo y además seguir uno de los principios de la programación orientada a objetos: la encapsulación de los datos en objetos.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.


Si te gustó el post, regálame tus aplausos!!!