¿Qué es el Factory Method?

Es uno de los patrones existentes creacionales


     Define una interfaz para crear un objeto, pero le permite a las subclases decidir cuál clase instanciar. El método abtracto le permite a una clase creadora abstracta delegar la instanciación a las subclases.

Diagrama

 

¿Cuándo usar este patrón?

• Se necesita desligar el cliente con el tipo de la clase concreta, esto también aplica al Abstract Factory.
• La clase creadora necesita delegar a sus clases derivadas la responsabilidad de escoger qué clase instanciar.
• En situaciones donde la lógica de creación de un objeto en la clase creadora concreta es más complicada que decidir cuál objeto  instanciar según uno o dos parámetros.
• La complejidad de creación de un objeto en la clase creadora concreta puede cambiar con el tiempo.

Principio SOLID: Responsabilidad única

El principio de responsabilidad única postula que una clase debería tener una única razón para cambiar. 

   La estructura de este patrón hace que las clases concretas creadoras implementen el <<factory method>> y estas deciden cuáles productos concretos crear, por esto, en el diseño original del patrón, estas clases creadoras solo tiene una única responsabilidad de saber cuál es la creación, instanciación o construcción de las clases (productos). Cada clase constructora se especializa e implementa la creación de uno o varios objetos (productos) de la base misma clase base.

     Una  variación del patrón permite a los <<factory methods>> crear distintas clases de productos, por lo que el método puede ser parametrizado. Esto no significa que la clase tenga que tener más de una responsabilidad porque aun sigue encargada de crear productos, más bien con esto debe de identificar el tipo de objeto por crear.


     La buena implementación de este patrón permite tener métodos y clases refactorizados de manera tal que cada uno tenga su única responsabilidad.

Principio SOLID: Abierto-Cerrado

     El principio de abierto-cerrado indica que las entidades de software (clases, módulos o funciones) debería estar abiertos para la extensión, pero cerrado para modificaciones); es decir una clase debe extender sin modificar su código fuente.

 

     El Factory Method sigue este principio pues los productos y los creadores concretos están cerrados para la modificación pues se pueden extender nuevos productos o fábricas concretas. 

     Si el Factory Method necesita soportar múltiples tipos de productos, entonces el método debe aceptar un parámetro indicando el objeto concreto por crear. Si más adelante, el cliente de la fábrica necesita crear un nuevo producto concreto, se debe instanciar una nueva clase creadora concreta para poder crear el producto.

     En el caso que el Factory Method deba producir más de un producto y sea parametrizado, se recomienda usar introspección en la implementación para agregar dinámicamente la clase por instanciar. 

Principio SOLID: Sustitución de Liskov

     Este principio indica que las subclases nunca deben violentar la definición del tipo de las clases base.


       Muchos podrían pensar que toda herencia cumple el principio Liskov, no obstante no siempre es así; ejemplo de un código que no cumple este principio se encuentra abajo. 


     Este patrón se basa en clases abstractas, por lo tanto no existe la manera que se violente el principio. 


     Al implementar una interfaz o heredar de una clase abstracta hace que las clases hijas nunca violenten la definición de las clases bases y pueden ser tratados como el mismo tipo de la base, por lo tanto no se violenta el principio.

Principio SOLID: Inversión de Dependencia

      El principio de Inversión de Dependencia (DIP, por sus siglas en inglés) lo que busca es desacoplar las clases a través de abstracciones, logrando así que las clases superiores interactúen con clases de nivel inferior sin conocerlas.

      Como se puede ver, el patrón Factory Method logra lo anterior pues, el cliente (superior) interactúa con una clase concreta (inferior) sin conocer sus detalles  mediante una abstracción o interfaz.

Principioo SOLID: Segregación de Interfaces

     El principio de Interfaz de Segregación evita que los clientes tengan que estar forzados a implementar interfaces que se utilicen. Cuando esto ocurre se le conoce como interfaz contaminada, que ocurre cuando se recurre a extiende una interfaz y se ve obligado el cliente a implementar una interfaz completa con métodos ficticios.

 

      Al relacionarse con el patrón Factory Method se refleja que sigue el principio, pues se pueden encontrar interfaces, las cuales las clases concretas implementan los métodos justos de manera más especifica sin ser forzarse a implementar métodos que no se necesiten.

 

Ejemplo de una implementación SOLID