Consiste en utilizar una clase constructora abstracta con unos cuantos métodos definidos y otro(s) abstracto(s). Es una simplificación del Abstract Factory, en la que la clase abstracta tiene métodos concretos que usan algunos de los abstractos; según usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento.
En si lo que hace este patrón es crear objetos de un tipo determinado en tiempo de ejecución. Consiste en un método para crear objetos (familias de objetos) cuando no sabemos la clase exacta del objeto que va a ser creado. De esta manera encapsulamos clases en una clase general de la que heredarán distintas subclases. Con este patrón se puede redefinir métodos en cada subclase, así como automatizar la creación de objetos utilizando variables.
Patrón útil para: crear objetos que tienen algo en común (comparten una interfaz).
Problema que resuelve este patrón: Crear un objeto sin especificar la clase a la que pertenece, la instancia del objeto a crear depende de condiciones externas a la clase. Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al cliente la elección el subtipo a crear.
Motivación: ¿Por qué complicarme tanto la vida utilizando un patrón de diseño, en lugar de instanciarla directamente $obj = new MiClase ()? Este patrón brinda Flexibilidad en tiempo de ejecución: A veces es imposible elegir de antemano cuál objeto específico debe ser instanciado, ya que la elección de los objetos a utilizar puede depender de algo en el entorno de ejecución.
Ejemplo: Vamos con nuestra cámara de fotos y un carro teledirigido una tienda de electricidad para comprar pilas. El enfoque “sencillo” (si aplicamos el patrón de diseño) es decirle al vendedor: “quiero pilas para estos elementos”. El enfoque complicado (no usar el patrón: instanciar cada objeto por separado) es decir: “quiero pilas AAA (de 1,5 V) para la cámara, una pila de petaca de 9V para el control y pilas AA para el carro”.
Para nuestro patrón la cámara, el control y el carro que serían nuestros objetos cliente se despreocupan de saber qué características tienen las pilas que usan, solo las necesitan para funcionar. Es tarea de nuestro patrón saber que pilas tiene que entregar y la forma de cómo hacerlo. Puede que hoy el patrón busque en un catálogo, mañana puede que consulte una base de datos y pasado mañana solicite un archivo XML, pero esto es algo que no les importa a nuestros clientes.
El patrón “Factory” es esto mismo. Un objeto especializado se encarga de instanciar objetos para clientes, y estos utilizan los métodos que proporciona la interfaz del objeto recibido, pero sin saber nada de las interioridades del objeto, ni siquiera qué tipo de objeto es (a partir de qué clase está instanciado).
Ejemplo2:
Las prensas de moldeado a inyección sirven para explicar este patrón. Los fabricantes de juguetes de plástico procesan plástico en polvo para moldeado, e inyectan el plástico en moldes con las formas deseadas. La clase de un juguete (auto, figura, etc.) es determinada por el molde.
Estructura:
Las clases principales en este patrón son el creador y el producto. El creador necesita crear instancias de productos, pero el tipo concreto de producto no debe ser forzado en las subclases del creador, porque entonces las posibles subclases del creador deben poder especificar subclases del producto para utilizar.
La solución para esto es hacer un método abstracto (el método de la fábrica) que se define en el creador. Este método abstracto se define para que devuelva un producto. Las subclases del creador pueden sobrescribir este método para devolver subclases apropiadas del producto.
Ventajas:
Aísla las clases de la implementación, ayuda a controlar los objetos que se crean, fomenta la consistencia entre objetos, facilita la escalabilidad del sistema, el usuario se abstrae de la instancia a crear.
Desventajas:
Puede ser difícil de incorporar y no tan bueno a la hora de incorporarse en pequeños códigos.