Factory Pattern: centralizar creación de objetos

Curso de Patrones de Diseño y SOLID en Python

Contenido del curso

Patrones de Diseño y Principios SOLID

1
Patrones de diseño y SOLID en Python
02:07 min

Principios SOLID

Reestructuración del proyecto

13
Reestructuración con módulos de Python y SOLID
13:32 min

Patrones de Diseño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:003:04

Factory Pattern: centralizar creación de objetos

Curso de Patrones de Diseño y SOLID en Python

Clase 17 de 27

Clase 17 / 27

Recursos

Crear sin acoplarte a clases concretas es posible con el patrón creacional Factory Pattern. Aquí verás cómo centralizar la lógica de instanciación, apoyarte en interfaces, abstracciones o protocolos en Python, y elegir el objeto adecuado en cada caso de uso para ganar flexibilidad, escalabilidad y desacoplamiento.

¿Qué es el factory pattern y por qué usarlo?

El Factory Pattern crea objetos sin especificar la clase concreta. En lugar de eso, se apoya en interfaces o abstracciones para devolver instancias válidas según un parámetro de tipo (por ejemplo, un string). Así, encapsula la lógica de creación y ofrece una interfaz común para construir objetos.

Centraliza decisiones de creación en una sola clase factory.
Reduce acoplamiento: el código cliente no conoce clases concretas.
Facilita extensibilidad: integrar un nuevo procesador solo requiere ampliar la factory.
Mantiene consistencia: una única forma de crear instancias en todo el sistema.

¿Cuándo aplicarlo para crear objetos?

Úsalo cuando múltiples clases comparten una interfaz común y necesitas decidir cuál instanciar según el contexto. También resulta clave cuando la creación requiere múltiples decisiones (validaciones, parámetros, tipos), haciendo que sea conveniente encapsular esa complejidad.

¿Cómo se relaciona con el patrón strategy?

El patrón Strategy define múltiples estrategias, clases o funciones que resuelven el mismo problema con distintas soluciones. La Factory selecciona la estrategia correcta para el caso de uso adecuado, delegando la elección de la implementación concreta.

¿Qué problemas resuelve al escalar el sistema?

Cuando necesitas integrar un tercer procesador u otro nuevo, la lógica está centralizada en la factory. No cambias el código cliente; solo extiendes la factory para soportar el nuevo tipo.

¿Cómo implementarlo con una factory y un servicio de pagos?

Imagina un diagrama con una clase de alto nivel, PaymentService, que depende de PaymentFactory. La factory expone un método, getProcessor, que elige el procesador según un tipo (string) y devuelve la instancia correcta. De este modo, cualquier parte del código puede solicitar instancias a la factory para procesar pagos sin conocer detalles de creación.

¿Qué responsabilidades tienen paymentservice y paymentfactory?

PaymentService: orquesta el proceso de pago y delega la elección del procesador a la factory.
PaymentFactory: contiene la lógica de decisión y el método getProcessor que devuelve el procesador correcto según el tipo.

¿Qué pasos seguir para aplicarlo?

Crear una clase Factory con un método que instancia y devuelve objetos basados en parámetros.
Encapsular la lógica de selección dentro de la factory (por ejemplo, por tipo).
Usar la factory en el código cliente para obtener instancias y mantener el desacoplamiento.
Extender la factory al integrar nuevos procesadores o features, sin modificar el cliente.

¿Has usado el Factory Pattern en tus proyectos? Cuéntame en comentarios cómo lo aplicaste y qué beneficios te dio.

Comentarios (7)7 comentarios

Mario Alexander Vargas Celis

Hace 2 años

El Patrón Factory es un patrón de diseño creacional que permite crear objetos sin especificar la clase exacta del objeto que se va a instanciar. Este patrón utiliza interfaces o clases abstractas para encapsular la lógica de creación, facilitando así la flexibilidad y la escalabilidad del código. Se utiliza especialmente cuando hay múltiples clases que comparten una interfaz común y se requiere decidir cuál de ellas crear en tiempo de ejecución. Esto centraliza la lógica de creación, haciendo que el sistema sea más mantenible y extensible.

Franco Manca

El patrón Factory en Python se caracteriza por:

Abstracción: Crea objetos sin especificar la clase exacta, utilizando interfaces o abstracciones.
Encapsulamiento: Centraliza la lógica de creación de objetos, simplificando la instancia de clases.
Flexibilidad: Permite añadir nuevos tipos de objetos sin modificar el código existente.

Cuándo aplicarlo:

Cuando hay múltiples clases que comparten una interfaz.
Cuando la creación de objetos requiere lógica compleja.

Cómo aplicarlo:

Crea una clase Factory con un método que instancie objetos basados en parámetros. Usa el Factory donde se requieran instancias, facilitando cambios futuros.

El **Patrón Factory** es un patrón de diseño creacional que proporciona una manera de crear objetos sin exponer la lógica de creación al cliente. En su lugar, el cliente utiliza un método común para crear las instancias necesarias. Este patrón es útil cuando la creación de objetos es compleja o depende de condiciones específicas.

### Conceptos Clave del Patrón Factory

1. **Encapsulación**: La lógica de creación de objetos está encapsulada en un método, función o clase específica.

2. **Simplicidad para el Cliente**: El cliente no necesita conocer los detalles sobre qué clase exacta está siendo instanciada.

3. **Extensibilidad**: Es fácil añadir nuevas clases sin modificar el código del cliente.

### Tipos de Patrón Factory

1. **Simple Factory**: Tiene un único método para crear instancias de diferentes clases.

2. **Factory Method**: Define una interfaz para crear objetos, dejando las subclases responsables de definir qué clase instanciar.

3. **Abstract Factory**: Proporciona una interfaz para crear familias de objetos relacionados o dependientes.

---

### Implementación del Patrón Factory en Python

Supongamos que estamos desarrollando un sistema para generar notificaciones (correo electrónico, SMS y push). Utilizaremos una **Simple Factory** para gestionar estas instancias.

#### Paso 1: Crear una Interfaz Común

Definimos una clase base que todas las notificaciones implementarán.


from abc import ABC, abstractmethod



class Notification(ABC):

&#x20;   @abstractmethod

&#x20;   def notify(self, message: str):

&#x20;       """Envía una notificación con el mensaje dado."""

&#x20;       pass

#### Paso 2: Implementar Clases Concretas

Creamos clases específicas para cada tipo de notificación.


class EmailNotification(Notification):

&#x20;   def notify(self, message: str):

&#x20;       print(f"Enviando correo electrónico: {message}")



class SMSNotification(Notification):

&#x20;   def notify(self, message: str):

&#x20;       print(f"Enviando SMS: {message}")



class PushNotification(Notification):

&#x20;   def notify(self, message: str):

&#x20;       print(f"Enviando notificación push: {message}")

#### Paso 3: Crear la Fábrica

La fábrica centraliza la lógica para instanciar las notificaciones según el tipo solicitado.


class NotificationFactory:

&#x20;   @staticmethod

&#x20;   def create\_notification(notification\_type: str) -> Notification:

&#x20;       if notification\_type == "email":

&#x20;           return EmailNotification()

&#x20;       elif notification\_type == "sms":

&#x20;           return SMSNotification()

&#x20;       elif notification\_type == "push":

&#x20;           return PushNotification()

&#x20;       else:

&#x20;           raise ValueError(f"Tipo de notificación desconocido: {notification\_type}")

#### Paso 4: Usar el Patrón Factory

Ahora podemos crear notificaciones sin preocuparnos por la lógica de instanciación.


\# Crear diferentes notificaciones usando la fábrica

notification1 = NotificationFactory.create\_notification("email")

notification1.notify("¡Hola! Este es un correo electrónico.")



notification2 = NotificationFactory.create\_notification("sms")

notification2.notify("¡Hola! Este es un SMS.")



notification3 = NotificationFactory.create\_notification("push")

notification3.notify("¡Hola! Esta es una notificación push.")

### Ventajas del Patrón Factory

1. **Simplicidad para el Cliente**: El cliente no necesita preocuparse por la lógica de creación de objetos.

2. **Centralización**: La lógica de creación se mantiene en un solo lugar, haciendo que el código sea más fácil de mantener.

3. **Extensibilidad**: Es sencillo añadir nuevas clases de notificación (o cualquier tipo de objeto) sin modificar la lógica existente en el cliente.

4. **Cumplimiento del Principio Abierto/Cerrado (OCP)**: Podemos extender el sistema con nuevos tipos de objetos sin cambiar la fábrica.

### Consideraciones

1. **Acoplamiento**: Si la fábrica crece demasiado, puede volverse un punto de acoplamiento fuerte.

2. **Complejidad Inicial**: Para problemas simples, el uso de una fábrica puede parecer innecesario.

### Variación: Usar Diccionarios en lugar de Condicionales

Podemos simplificar la implementación de la fábrica utilizando un diccionario para mapear tipos de notificaciones a sus clases concretas.


class NotificationFactory:

&#x20;   \_notification\_classes = {

&#x20;       "email": EmailNotification,

&#x20;       "sms": SMSNotification,

&#x20;       "push": PushNotification,

&#x20;   }



&#x20;   @staticmethod

&#x20;   def create\_notification(notification\_type: str) -> Notification:

&#x20;       notification\_class = NotificationFactory.\_notification\_classes.get(notification\_type)

&#x20;       if not notification\_class:

&#x20;           raise ValueError(f"Tipo de notificación desconocido: {notification\_type}")

&#x20;       return notification\_class()

Esto elimina los condicionales, haciendo que el código sea más limpio y fácil de mantener.

### Conclusión

El **Patrón Factory** en Python es una herramienta poderosa para gestionar la creación de objetos, especialmente cuando el proceso de instanciación es complejo o depende de condiciones dinámicas. Este patrón mejora la organización y extensibilidad del código, promoviendo prácticas de diseño robustas.

Ronaldo Jiménez


from abc import ABC, abstractmethod

# Producto abstracto
class Transporte(ABC):
    @abstractmethod
    def mover(self):
        pass

# Productos concretos
class Coche(Transporte):
    def mover(self):
        return "El coche se está moviendo por carretera"

class Bicicleta(Transporte):
    def mover(self):
        return "La bicicleta se está moviendo por el carril bici"

# Clase creadora abstracta
class CreadorTransporte(ABC):
    @abstractmethod
    def crear_transporte(self):
        pass

# Creadores concretos
class CreadorCoche(CreadorTransporte):
    def crear_transporte(self):
        return Coche()

class CreadorBicicleta(CreadorTransporte):
    def crear_transporte(self):
        return Bicicleta()

# Uso del patrón Factory Method
def cliente(creador: CreadorTransporte):
    transporte = creador.crear_transporte()
    print(transporte.mover())

# Crear un coche
cliente(CreadorCoche())  # Salida: "El coche se está moviendo por carretera"

# Crear una bicicleta
cliente(CreadorBicicleta())  # Salida: "La bicicleta se está moviendo por el carril bici"

edgardo ponce

falto agregar la documentación que se fue agregando a todos las otras clases.

Ray Trápala

No sé si puede dcirse que lo aplique pero cuando tengo esos casos tengo una clase factory que recibe, por decir, el nombre de un exchange (mi proyecto es un bot de trading) y este "factory" busca en un diccionario que tengo donde la llave es el nombre del exchange y el valor la referencia de la clase y ya crea el objeto y lo retorna

Eduardo José Álvarez

Team Platzi

sí, es una forma de implementar un patrón Factory. La lógica para decidir qué implementación está representada por un diccionario, totalmente válido

Bryann Andrei Valderrama Avila

¿Este es el mismo Abstract Factory?

Platzi

Factory Pattern y Abstract Factory son diferentes. En esta clase se abordó el Factory Pattern, no el Abstract Factory.

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Qué es el principio de responsabilidad única

Procesador de pagos en Python con Stripe

Cómo aplicar SRP en un procesador de pagos con Stripe

Principio open-closed en Python

Clases abstractas y principio abierto-cerrado

Principio de Liskov en S.O.L.I.D.

Principio de sustitución de Liskov en Python

Principio de segregación de interfaces en SOLID

Segregación de interfaces en procesadores de pagos

Principio de inversión de dependencias en SOLID

Principio de inversión de dependencias: servicio de pagos flexible

Reestructuración del proyecto

Reestructuración con módulos de Python y SOLID

Patrones de Diseño

Qué son los patrones de diseño: definición y categorías

Strategy Pattern con Python y setprocessor

Strategy Pattern para pagos en Python

Factory Pattern: centralizar creación de objetos

Patrón Factory para procesar pagos con match

Qué es el patrón Decorator

Patrón decorador en servicios de pagos

Builder Pattern: construcción paso a paso

Builder Pattern aplicado a un servicio de pagos

Observer Pattern en sistemas de eventos

Observer en sistemas de pagos con Python

Chain of Responsibility para validar pagos

Chain of Responsibility en servicios de pagos

Código funcional vs código mantenible en Python

Factory Pattern: centralizar creación de objetos

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos