Patrones De Diseño · DacaCode

Patrones de Diseño: Factory

Dacadev — Tue, 07 Jul 2026 00:00:00 +0000

Tabla de Contenido

La instanciación directa de clases concretas es uno de los puntos más costosos de acoplamiento en un diseño orientado a objetos. Cada new o llamada explícita a un constructor ata al cliente a una implementación específica, dificultando la extensión y la sustitución de componentes. Los patrones factory encapsulan esa decisión en un lugar controlado, permitiendo evolucionar la creación de objetos sin propagar cambios a todo el código consumidor.

Note

🚀 Los patrones factory encapsulan la creación de objetos y desacoplan al cliente de las clases concretas que necesita instanciar.

Este artículo forma parte de la serie de patrones de diseño. Analizaremos tres variantes de fabricación (Simple Factory, Factory Method y Abstract Factory), su relación con el Principio de Inversión de Dependencias y los trade-offs que conviene considerar al elegir uno u otro.

Simple Factory

El Simple Factory no es un patrón de diseño formal del catálogo GoF, sino un idiom recurrente: encapsular la lógica de creación de objetos dentro de un método (usualmente estático) que decide qué instancia devolver en función de un parámetro. Es un buen punto de partida para entender los patrones que veremos a continuación.

Info

GoF significa “Gang of Four” (la “Banda de los Cuatro”): los cuatro autores del libro Design Patterns (1994) que catalogó los 23 patrones de diseño clásicos. Cuando decimos que un patrón “es GoF”, significa que aparece en ese catálogo original.

Supongamos una pizzería que produce distintos tipos de pizzas. Sin un factory, el cliente tendría que conocer todas las clases concretas y decidir cuál instanciar. Con un SimpleFactory esa decisión queda centralizada:

classDiagram
 class PizzaStore {
 -factory: SimplePizzaFactory
 +order_pizza(kind) Pizza
 }
 class SimplePizzaFactory {
 +create_pizza(kind) Pizza
 }
 class Pizza {
 <<abstract>>
 +prepare()
 +bake()
 +box()
 }
 class CheesePizza
 class VeggiePizza
 class PepperoniPizza

 PizzaStore --> SimplePizzaFactory : usa
 SimplePizzaFactory ..> Pizza : crea
 Pizza <|-- CheesePizza
 Pizza <|-- VeggiePizza
 Pizza <|-- PepperoniPizza

Implementación mínima en Python:

from abc import ABC, abstractmethod


class Pizza(ABC):
 @abstractmethod
 def prepare(self) -> None: ...

 def bake(self) -> None:
 print("Horneando la pizza")

 def box(self) -> None:
 print("Empacando la pizza")


class CheesePizza(Pizza):
 def prepare(self) -> None:
 print("Preparando pizza de queso")


class VeggiePizza(Pizza):
 def prepare(self) -> None:
 print("Preparando pizza vegetariana")


class SimplePizzaFactory:
 def create_pizza(self, kind: str) -> Pizza:
 if kind == "cheese":
 return CheesePizza()
 if kind == "veggie":
 return VeggiePizza()
 raise ValueError(f"Tipo de pizza no soportado: {kind}")


class PizzaStore:
 def __init__(self, factory: SimplePizzaFactory) -> None:
 self.factory = factory

 def order_pizza(self, kind: str) -> Pizza:
 pizza = self.factory.create_pizza(kind)
 pizza.prepare()
 pizza.bake()
 pizza.box()
 return pizza

El cliente (PizzaStore) ya no depende de las clases concretas; toda la lógica de selección vive en el factory. La limitación es evidente: si necesitamos que distintas sucursales produzcan variantes propias de cada pizza, el if/elif termina explotando. Ese es exactamente el problema que resuelve Factory Method.

Info

El Simple Factory es útil como técnica de refactor cuando queremos aislar una serie de condicionales de creación, pero no ofrece extensibilidad vía herencia.

Factory Method

Note

El Factory Method define una interfaz para crear un objeto, pero delega en las subclases la decisión de qué clase concreta instanciar.

En lugar de tener una única clase factory que decide con condicionales, el Factory Method define un método abstracto de creación en la superclase. Cada subclase implementa ese método y devuelve el producto concreto que corresponda. La instanciación se difiere a las subclases.

classDiagram
 class Creator {
 <<abstract>>
 +factory_method() Product
 +operation()
 }
 class ConcreteCreatorA {
 +factory_method() Product
 }
 class ConcreteCreatorB {
 +factory_method() Product
 }
 class Product {
 <<abstract>>
 }
 class ConcreteProductA
 class ConcreteProductB

 Creator <|-- ConcreteCreatorA
 Creator <|-- ConcreteCreatorB
 Product <|-- ConcreteProductA
 Product <|-- ConcreteProductB
 ConcreteCreatorA ..> ConcreteProductA : crea
 ConcreteCreatorB ..> ConcreteProductB : crea

Consideremos un ejemplo canónico: una jerarquía de animales donde cada subclase decide qué instancia producir. La superclase define el flujo (show_animal) que consume el producto creado por el factory_method:

from abc import ABC, abstractmethod


class Animal(ABC):
 @abstractmethod
 def make_sound(self) -> str: ...

 @abstractmethod
 def create_animal(self) -> "Animal": ...

 def show_animal(self) -> None:
 animal = self.create_animal()
 print(f"El animal dice: {animal.make_sound()}")


class Dog(Animal):
 def make_sound(self) -> str:
 return "Guau!"

 def create_animal(self) -> Animal:
 return Dog()


class Cat(Animal):
 def make_sound(self) -> str:
 return "Miau!"

 def create_animal(self) -> Animal:
 return Cat()


Dog().show_animal() # El animal dice: Guau!
Cat().show_animal() # El animal dice: Miau!

El punto clave es que Animal.show_animal es agnóstico a la clase concreta: opera sobre la abstracción Animal y delega la instanciación a create_animal. Añadir un nuevo animal implica una nueva subclase, no modificar código existente — cumpliendo el principio abierto/cerrado.

Tip

Factory Method depende de herencia: cada subclase implementa el método de creación. Es ideal cuando la variación entre productos está atada a la variación de la clase creadora.

Abstract Factory

Mientras Factory Method crea un producto, el Abstract Factory crea familias completas de productos relacionados sin acoplar al cliente a las clases concretas de cada familia.

Un caso clásico: una aplicación que renderiza componentes de UI para distintos sistemas operativos. Botones y checkboxes de Windows deben usarse juntos, igual que los de macOS; mezclarlos rompe la coherencia visual. El Abstract Factory garantiza que solo se combinen componentes de la misma familia.

classDiagram
 class GUIFactory {
 <<abstract>>
 +create_button() Button
 +create_checkbox() Checkbox
 }
 class WindowsFactory
 class MacFactory
 class Button {
 <<abstract>>
 +render()
 }
 class Checkbox {
 <<abstract>>
 +render()
 }
 class WindowsButton
 class WindowsCheckbox
 class MacButton
 class MacCheckbox

 GUIFactory <|-- WindowsFactory
 GUIFactory <|-- MacFactory
 Button <|-- WindowsButton
 Button <|-- MacButton
 Checkbox <|-- WindowsCheckbox
 Checkbox <|-- MacCheckbox
 WindowsFactory ..> WindowsButton : crea
 WindowsFactory ..> WindowsCheckbox : crea
 MacFactory ..> MacButton : crea
 MacFactory ..> MacCheckbox : crea

Implementación en Python:

from abc import ABC, abstractmethod


class Button(ABC):
 @abstractmethod
 def render(self) -> None: ...


class Checkbox(ABC):
 @abstractmethod
 def render(self) -> None: ...


class WindowsButton(Button):
 def render(self) -> None:
 print("Renderizando botón de Windows")


class WindowsCheckbox(Checkbox):
 def render(self) -> None:
 print("Renderizando checkbox de Windows")


class MacButton(Button):
 def render(self) -> None:
 print("Renderizando botón de macOS")


class MacCheckbox(Checkbox):
 def render(self) -> None:
 print("Renderizando checkbox de macOS")


class GUIFactory(ABC):
 @abstractmethod
 def create_button(self) -> Button: ...

 @abstractmethod
 def create_checkbox(self) -> Checkbox: ...


class WindowsFactory(GUIFactory):
 def create_button(self) -> Button:
 return WindowsButton()

 def create_checkbox(self) -> Checkbox:
 return WindowsCheckbox()


class MacFactory(GUIFactory):
 def create_button(self) -> Button:
 return MacButton()

 def create_checkbox(self) -> Checkbox:
 return MacCheckbox()


class Application:
 def __init__(self, factory: GUIFactory) -> None:
 self.factory = factory

 def create_ui(self) -> None:
 button = self.factory.create_button()
 checkbox = self.factory.create_checkbox()
 button.render()
 checkbox.render()


factory: GUIFactory = WindowsFactory() # o MacFactory()
Application(factory).create_ui()

Application depende exclusivamente de GUIFactory, Button y Checkbox — todas abstracciones. Cambiar de familia consiste en inyectar una factory distinta; el resto del código permanece intacto.

Factory Method vs Abstract Factory

Aunque comparten espíritu, no son intercambiables:

Factory Method usa herencia: la subclase decide qué producto crear implementando un método.
Abstract Factory usa composición: el cliente recibe una factory y llama a varios métodos de creación sobre ella, obteniendo una familia de productos coherentes.
Factory Method escala en la dimensión de “un producto que varía”; Abstract Factory escala en la dimensión de “múltiples productos que varían de forma correlacionada”.

Static Factory

El Static Factory es una variante ligera que expone métodos de clase estáticos para construir instancias, en lugar de exponer constructores públicos. Es común en librerías del ecosistema Java y en APIs de Python que ofrecen métodos como datetime.now() o Path.home().

class Connection:
 def __init__(self, dsn: str) -> None:
 self._dsn = dsn

 @classmethod
 def from_env(cls) -> "Connection":
 import os
 return cls(dsn=os.environ["DATABASE_URL"])

 @classmethod
 def in_memory(cls) -> "Connection":
 return cls(dsn="sqlite://:memory:")

Ventajas: los métodos estáticos pueden tener nombres semánticos (from_env, in_memory) que documentan la intención mucho mejor que un constructor sobrecargado. Limitación: no permite polimorfismo — no es reemplazable en tiempo de ejecución como sí lo son Factory Method o Abstract Factory.

Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias (DIP, la “D” de SOLID) enuncia dos reglas:

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
Las abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones.

Los patrones factory son una herramienta natural para aplicar DIP: al centralizar la creación en una abstracción, el módulo de alto nivel deja de instanciar clases concretas. Volviendo al ejemplo de la pizzería:

flowchart LR
 subgraph Antes["Sin DIP"]
 A1[PizzaStore] --> A2[CheesePizza]
 A1 --> A3[VeggiePizza]
 A1 --> A4[PepperoniPizza]
 end
 subgraph Despues["Con DIP + Factory"]
 B1[PizzaStore] --> B2[Pizza abstracta]
 B3[CheesePizza] --> B2
 B4[VeggiePizza] --> B2
 B5[PepperoniPizza] --> B2
 end

En “Antes”, el flujo de dependencia va de alto a bajo nivel: PizzaStore conoce todas las pizzas concretas. En “Después”, ambos dependen de la abstracción Pizza: la dependencia queda invertida.

Un ejemplo aislado en Python que muestra el patrón:

from abc import ABC, abstractmethod


class MessageSender(ABC):
 @abstractmethod
 def send(self, message: str) -> None: ...


class EmailSender(MessageSender):
 def send(self, message: str) -> None:
 print(f"Enviando email: {message}")


class SmsSender(MessageSender):
 def send(self, message: str) -> None:
 print(f"Enviando SMS: {message}")


class NotificationService:
 def __init__(self, sender: MessageSender) -> None:
 self._sender = sender

 def notify(self, message: str) -> None:
 self._sender.send(message)


NotificationService(EmailSender()).notify("Nuevo despliegue exitoso")

NotificationService no conoce EmailSender ni SmsSender; solo la abstracción MessageSender. Un factory puede alimentar esa dependencia según configuración, entorno o feature flags, sin tocar NotificationService.

Consideraciones

Todos los factories encapsulan la creación de objetos y reducen el acoplamiento a implementaciones concretas.
Simple Factory no es un patrón GoF; es un idiom útil para aislar condicionales de creación en un único lugar.
Factory Method depende de herencia: cada subclase implementa el método de creación y decide el producto concreto.
Abstract Factory depende de composición: el cliente recibe una factory y obtiene familias de productos coherentes.
Los tres refuerzan el Principio de Inversión de Dependencias al hacer que el código cliente dependa de abstracciones, no de tipos concretos.
El DIP es una guía transversal, no un patrón: aplica siempre que quieras evitar el acoplamiento con implementaciones específicas.
Factory es una técnica de diseño, no una clase específica. Su nombre puede variar (build, create, from_x), lo importante es la intención: encapsular la construcción de objetos.

Note

🚀 Elige Simple Factory para aislar condicionales, Factory Method cuando la variación está atada a la jerarquía del creador, y Abstract Factory cuando necesitas coherencia entre múltiples productos relacionados.

Continúa la serie

Si te interesa seguir explorando patrones de diseño, revisa los otros artículos de la serie:

Patrones de Diseño: Decorador

Dacadev — Wed, 21 Feb 2024 21:25:17 +0000

Tabla de Contenido

Objetivo del patrón decorador

Note

El patrón decorador agrega dinamismo a la extensión de funcionalidades.

El objetivo del patrón decorador es crear una clase abstracta, la cual usaremos para crear (a través de herencia) los objetos base. Los decoradores serán clases especiales que extienden las funcionalidades de la clase abstracta, agregando un campo que contendrá una instancia de la clase abstracta, o en su defecto, un hijo de la misma.

Veamos un ejemplo de cómo los decoradores pueden funcionar. Supongamos que estamos creando una aplicación para llevar el control de costos de bebidas, donde el costo de estas bebidas depende de los ingredientes adicionales que le añadamos, como por ejemplo, chocolate rallado, crema, etc.

Ejemplo de uso

Ahora, supongamos que tenemos una clase base café a la cual queremos agregar dos ingredientes nuevos: chocolate y crema chantilly. Gráficamente, se vería algo como

De este ejemplo, podemos ver que para calcular el costo total de la bebida debemos sumar el valor de costo de cada uno de los decoradores o de las clases decoradoras. Para ello, la clase base debe tener la capacidad de identificar si tiene un hijo para retornar su valor de costo por defecto y así encadenar la suma.

Antes de pasar al código de implementación, veamos algunas características que debemos tener en cuenta para este patrón.

Características del patrón decorador

El decorador debe tener el mismo supertipo que el objeto que están decorando; es decir, ambas clases, la clase decoradora y la que se está decorando, deben heredar de la misma clase.
Puedes usar uno o más decoradores para encapsular un objeto, lo que significa que no hay límite en la cantidad de objetos decoradores que se utilicen sobre un objeto.
Cuando se le da el mismo supertipo al decorado y a la clase que está decorando, podemos pasar dicho elemento decorado en lugar del objeto original encapsulado.
El decorador agrega su propio comportamiento antes o después de que el objeto decorado realice su trabajo.
Los objetos pueden ser decorados en cualquier momento, lo que permite que sean decorados de manera dinámica en tiempo de ejecución.

Note

🚀 El patrón decorador adiciona responsabilidades de manera dinámica a un objeto, ofreciendo flexibilidad y una alternativa al uso de subclases.

Implementación del ejemplo en código

Teoría

Para la implementación de nuestro ejemplo, veamos como funcionaría el diagrama de clases

classDiagram
 class Component {
 methodA()
 methodB()
 otherMethods()
 }
 class ConcreteComponent {
 methodA()
 methodB()
 }
 class Decorator {
 WrappedObj Component
 methodA()
 methodB()
 otherMethods()
 }
 class ConcreteDecoratorA {
 WrappedObj Component
 methodA()
 methodB()
 otherMethods()
 }
 class ConcreteDecoratorB {
 WrappedObj Component
 methodA()
 methodB()
 otherMethods()
 }
 Component <|-- ConcreteComponent
 Component <|-- Decorator
 Decorator <|-- ConcreteDecoratorA
 Decorator <|-- ConcreteDecoratorB

Tendremos una clase base (nuestra clase abstracta) que en el diagrama se llama Component. De esta clase creamos dos clases: una es la clase ConcreteComponent, que es la que usaremos para instanciar nuestros objetos, y otra clase llamada Decorator, que es la que usaremos para crear todos los decoradores que podemos usar con nuestro objeto ConcreteComponent.

Decorator es una clase abstracta que será usada para crear nuestros decoradores específicos. Esta clase definirá los métodos y demás lógica que debe ser implementada para que otras clases sean decoradores válidos.

Ejemplo

Aplicando el anterior esquema a un ejemplo, podemos suponer que queremos crear tipos de bebidas que varían su combinación

classDiagram
 class Beverage {
 -description
 +getDescription()
 +cost()
 }
 class Coffee {
 +cost()
 }
 class Decaf {
 +cost()
 }
 class HouseBlend {
 +cost()
 }
 class IngredientDecorator {
 -beverage Beverage
 +getDescription()
 }
 class Milk {
 +cost()
 +getDescription()
 }
 class Mocha {
 +cost()
 +getDescription()
 }
 class Soy {
 +cost()
 +getDescription()
 }
 class Chantilly {
 +cost()
 +getDescription()
 }
 class Chocolate {
 +cost()
 +getDescription()
 }
 Beverage <|-- Coffee
 Beverage <|-- Decaf
 Beverage <|-- HouseBlend
 Beverage <|-- IngredientDecorator
 IngredientDecorator <|-- Milk
 IngredientDecorator <|-- Mocha
 IngredientDecorator <|-- Soy
 IngredientDecorator <|-- Chantilly
 IngredientDecorator <|-- Chocolate

La implementación del anterior diagrama se haría de la siguiente manera (en Python) empezaremos por la implementación de las clases abstractas

from abc import ABC


class Beverage(ABC):
 def cost(self) -> float:
 pass

 def description(self) -> str:
 pass


class IngredientDecorator(ABC):
 def __init__(self, beverage: Beverage):
 self.beverage = beverage

 def cost(self) -> float:
 pass

 def description(self) -> str:
 pass

Ahora haciendo uso de nuestras clases abstractas, podemos crear nuestros objetos y decoradores concretos, nuestros objetos lucirían de la siguiente forma:

from abc_classes import Beverage


class Coffee(Beverage):
 def cost(self) -> float:
 return 1.99

 def description(self) -> str:
 return "Coffee"


class Decaf(Beverage):
 def cost(self) -> float:
 return 1.25

 def description(self) -> str:
 return "Decaf"


class HouseBlend(Beverage):
 def cost(self) -> float:
 return 0.89

 def description(self) -> str:
 return "House Blend"

y nuestros decoradores

from abc_classes import IngredientDecorator


class Milk(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.10

 def description(self) -> str:
 return self.beverage.description() + ", Milk"


class Mocha(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.20

 def description(self) -> str:
 return self.beverage.description() + ", Mocha"


class Soy(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.15

 def description(self) -> str:
 return self.beverage.description() + ", Soy"


class Chantilly(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.25

 def description(self) -> str:
 return self.beverage.description() + ", Chantilly"


class Chocolate(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.30

 def description(self) -> str:
 return self.beverage.description() + ", Chocolate"

y su uso dentro de nuestro código sería

from concrete_classes import Coffee, Decaf, HouseBlend
from decorators import Milk, Mocha, Soy, Chantilly, Chocolate

if __name__ == "__main__":

 chocolate_blend = Chantilly(Chocolate(HouseBlend()))
 soy_decaf = Soy(Decaf())
 moccachino = Mocha(Chocolate(Milk(Coffee())))

 print(chocolate_blend.cost())
 print(chocolate_blend.description())

 print(soy_decaf.cost())
 print(soy_decaf.description())

 print(moccachino.cost())
 print(moccachino.description())

cuando ejecutemos este código podremos ver que en nuestro resultado obtendremos

1.44
House Blend, Chocolate, Chantilly
1.4
Decaf, Soy
2.59
Coffee, Milk, Chocolate, Mocha

Consideraciones del patrón decorador

la herencia es una forma de extensión, pero no necesariamente la mejor forma de alcanzar la flexibilidad de nuestros diseños
En nuestros diseños debemos de habilitar la extensión de nuevos comportamientos evitando la modificación del código actual
la composición y la delegación pueden ser usados para agregar nuevos comportamientos en tiempo de ejecución
El patrón decorador provee una alternativa al uso de subclases para extender el comportamiento
El patrón decorador involucra el uso de clases decoradores que son usadas para encapsular componentes del mismo tipo en concreto
Las clases decoradoras tienen el mismo tipo de la clase que decoran o encapsulan
Los decoradores agregan nuevos comportamientos antes o después de que el objeto encapsulado realiza su trabajo
Los decoradores normalmente son transparentes al cliente del componente
Los decoradores pueden resultar en muchos objetos pequeños en nuestros diseños y el sobre uso del mismo puede derbar en crear código complejo y difícil de mantener

Patrones de Diseño: Observador

Dacadev — Mon, 08 Jan 2024 01:25:17 +0000

Tabla de Contenido

Note

El patrón observador define una relación uno-a-muchos entre objetos: cuando un objeto cambia de estado, todos sus dependientes son notificados automáticamente.

Teoría

El patrón observador es muy útil cuando se desea actualizar diversos objetos en función de los cambios en otros, siendo ampliamente implementado en frameworks frontend como React o Vue.

Este patrón se basa en dos partes clave: los publishers u observables, que son los objetos emisores de valores, y los suscriptores, conocidos como observadores o subscribers. Estos últimos reciben los valores emitidos por los publishers.

Note

Publishers + Suscribers = Observer Pattern

La esencia de este patrón es permitir que un publisher emita eventos a sus subscribers, teniendo además la capacidad de agregar o eliminar suscriptores de sus listas.

Veamos gráficamente cómo funciona este patrón.

En el caso 1, observamos un Objeto Publisher emitiendo valores constantemente, compartidos con todos los Suscribers registrados en su lista. En este ejemplo, no hay suscriptores.

En el caso 2, dos objetos están suscritos al objeto Publisher, recibiendo el valor emitido en el momento de su emisión.

Note

El patrón Observer permite relacionar objetos de manera comprensible, eficiente y mantenible. Es una relación One-to-Many.

Implementación

Implementaremos el patrón observer en Python definiendo dos clases abstractas: Publisher y Subscriber. Luego, crearemos clases derivadas que emitan valores (Publisher) y que se registren para recibir datos (Subscribers).

Comenzamos con las clases abstractas:

from abc import ABC, abstractmethod

class Suscriber(ABC):
 def __init__(self):
 pass

 @abstractmethod
 def update(self, value) -> None:
 raise NotImplementedError("You must implement this method")

class Publisher(ABC):
 def __init__(self):
 self.subscribers: list[Suscriber] = list()

 def add_suscriber(self, subscriber: Suscriber):
 self.subscribers.append(subscriber)

 def remove_suscriber(self, suscriber: Suscriber):
 self.subscribers.remove(suscriber)

 def notify_suscribers(self, value):
 for suscriber in self.subscribers:

En este código, definimos dos clases:

Subscriber: Representa a los suscriptores o observadores, exigiendo la implementación del método update, que recibe el dato actualizado.
Publisher: Define tres métodos clave: - add_subscriber: Registra un nuevo suscriptor. - remove_subscriber: Elimina un suscriptor específico. - notify_subscribers: Actualiza el valor a todos los suscriptores.

Note

Este código es una guía sobre cómo funciona el patrón y puede mejorarse según las necesidades de cada proyecto.

Ahora, implementemos este patrón en un ejemplo práctico: un sistema de IoT en casa que mide la radiación ultravioleta. Queremos compartir estos datos con dos sistemas: uno que almacena información para la protección infantil contra los rayos UV y otro para un sistema de riego basado en estas mediciones.

Implementaremos tres clases:

UVSolarSystem (Publisher)
UVTracker (Suscriber)
UVPlantTracker (Suscriber)

class UVSolarSystem(Publisher):

 def emit_value(self):
 value = randint(0, 100)
 self.notify_suscribers(value)

class UVTracker(Suscriber):

 def update(self, value) -> None:
 print(f"UVTracker: {value}")
 print("Doing funny stuff with this value :D")

class UVPlantTracker (Suscriber):

 def update(self, value) -> None:
 print(f"UVPlantTracker: {value}")
 print("Doing funny stuff for the plants with this value :D")

En el código, el método emit_value en UVSolarSystem es personalizado y utiliza notify_subscribers. Las clases Subscriber implementan el método update.

Probemos el código:

print("Stage 1".center(50, "="))
# define the publisher
solar_system = UVSolarSystem()

solar_system.emit_value()

print("Stage 2".center(50, "="))
# first suscriber
uv_tracker = UVTracker()

solar_system.add_suscriber(uv_tracker)
solar_system.emit_value()

print("Stage 3".center(50, "="))
# second suscriber
uv_plant_tracker = UVPlantTracker()

solar_system.add_suscriber(uv_plant_tracker)
solar_system.emit_value()

print("Stage 4".center(50, "="))
# remove the first suscriber
solar_system.remove_suscriber(uv_tracker)

La salida sería

>>> $ python main.py
=====================Stage 1======================
=====================Stage 2======================
UVTracker: 2
Doing funny stuff with this value :D
=====================Stage 3======================
UVTracker: 79
Doing funny stuff with this value :D
UVPlantTracker: 79
Doing funny stuff for the plants with this value :D
=====================Stage 4======================
UVPlantTracker: 73

Podemos mejorar el Publisher inicial agregando la posibilidad de retener el último valor emitido. Esto permite a los suscriptores acceder al valor cuando lo necesiten. El cambio en la clase Publisher sería:

class PublisherImprove(ABC):
 def __init__(self) -> None:
 self.subscribers: list[Suscriber] = list()
 self._value = None

 def add_suscriber(self, subscriber: Suscriber):
 self.subscribers.append(subscriber)

 def remove_suscriber(self, suscriber: Suscriber):
 self.subscribers.remove(suscriber)

 def notify_suscribers(self):
 for suscriber in self.subscribers:
 suscriber.update(self._value)

 @property
 def get_value(self):
 return self._value

Agregamos el getter get_value para acceder al valor actual del Publisher, alojado como atributo privado self._value.

Consideraciones del patrón observador

Define una relación one-to-many entre objetos.
Los observables actualizan a los observadores a través de una interfaz común.
Cualquier observador puede participar si cumple con la interfaz común.
Los observadores deben estar desacoplados del observable.
Es posible acceder a los datos del observable cuando sea necesario, en vez de esperar cada evento.

Patrones de Diseño: Estrategia

Dacadev — Thu, 28 Dec 2023 01:25:17 +0000

Tabla de Contenido

Note

El patrón estrategia define una familia de algoritmos intercambiables, encapsulando cada uno de ellos para que puedan ser usados de manera flexible en tiempo de ejecución.

Este patrón consiste en definir/identificar un conjunto de comportamientos comunes de un objeto y encapsular dichos comportamientos como una familia de algoritmos que, por definición, serán comunes entre ellos. De esta manera, si un objeto hace uso de dichos comportamientos, cada uno de ellos sería reemplazable por alguno de la misma familia.

Apliquemos el concepto agnóstico y posteriormente lo aplicaremos en código.

Supongamos que queremos crear un conjunto de clases que estén relacionadas con aves. Cada una de nuestras aves tendrá la capacidad de volar. Para aplicar el patrón estrategia, debemos identificar primero cuáles son esos comportamientos comunes que tienen nuestro conjunto de clases (Aves), para lo cual sería el método de volar, y vamos a encapsular este tipo de comportamiento. Esta idea se ilustra en el siguiente diagrama:

classDiagram
 class Ave {
 +volar()
 }
 class NoVolar {
 ejecutarVuelo()
 }
 class SiVolar {
 ejecutarVuelo()
 }
 ComportamientoVolar <|-- NoVolar
 ComportamientoVolar <|-- SiVolar
 class ComportamientoVolar {
 +ejecutarVuelo()
 }
 Ave <|-- Pato
 Ave <|-- Gallina
 Ave --|> ComportamientoVolar

Para este proceso optaremos por definir las clases abstractas de Aves y del comportamiento de volar, de esta manera podemos crear nuestras diversas clases y estas podrán emplear cualquiera de las clases que implementen la clase base de comportamientoVolar.

Este código implementado en Python se vería de la siguiente manera:

from abc import ABC, abstractclassmethod

# Clases abstractas
class FlightBehavior(ABC):
 def __init__(self):
 pass

 @abstractclassmethod
 def execute_fly(self):
 pass

class Bird(ABC):
 def __init__(self, flys_behavior: FlightBehavior):
 self.flys_behavior = flys_behavior

 def fly(self):
 self.flys_behavior.execute_fly()

# Cómo utilizarlo
# 1. Definir las clases que implementan las clases abstractas

# Estrategias
class NoFly(FlightBehavior):
 def __init__(self):
 super().__init__()

 def execute_fly(self):
 print("I can't fly")

class Fly(FlightBehavior):
 def __init__(self):
 super().__init__()

 def execute_fly(self):
 print("I can fly")

# Clases que implementan la estrategia
class Hen(Bird):
 def __init__(self, flys_behavior: FlightBehavior):
 super().__init__(flys_behavior=flys_behavior)

class Duck(Bird):
 def __init__(self, flys_behavior: FlightBehavior):
 super().__init__(flys_behavior=flys_behavior)

# 2. Crear los objetos
if __name__ == '__main__':
 hen = Hen(NoFly())
 hen.fly()

 duck = Duck(Fly())
 duck.fly()

Este patrón es útil en situaciones en las que tienes una clase que tiene varios comportamientos y quieres que el comportamiento se seleccione en tiempo de ejecución, según las necesidades de tu aplicación. Por ejemplo, puedes tener una clase que realiza operaciones matemáticas y quieres poder cambiar la operación que realiza en tiempo de ejecución, según las necesidades de la aplicación.

Tip

El patrón estrategia es ideal cuando tienes múltiples algoritmos para una tarea y necesitas cambiar entre ellos de forma dinámica. Piensa en sistemas de pago, algoritmos de ordenamiento o validaciones configurables.

A continuación, un ejemplo de Python de este caso de cambio de estrategia en tiempo de ejecución:

from abc import ABC, abstractmethod

class Context:
 def __init__(self, strategy: 'Strategy') -> None:
 self._strategy = strategy

 def execute_strategy(self, x: int, y: int) -> int:
 return self._strategy.execute(x, y)

class Strategy(ABC):
 @abstractmethod
 def execute(self, x: int, y: int) -> int:
 pass

class AddStrategy(Strategy):
 def execute(self, x: int, y: int) -> int:
 return x + y

class SubtractStrategy(Strategy):
 def execute(self, x: int, y: int) -> int:
 return x - y

# Uso de las clases
context = Context(AddStrategy())
print(context.execute_strategy(10, 5)) # Salida: 15

context = Context(SubtractStrategy())
print(context.execute_strategy(10, 5)) # Salida: 5

Patrones de diseño: Qué son?

Dacadev — Sat, 02 Dec 2023 00:29:10 +0000

Tabla de Contenido

Los patrones de diseño, en general, se pueden definir como soluciones estandarizadas a problemas comunes en el diseño de software. No son fragmentos de código específicos, sino más bien guías o plantillas que se pueden aplicar en diversos contextos de programación.

Estos patrones son especialmente útiles porque permiten reutilizar conocimientos y enfoques que han sido probados y perfeccionados a lo largo de los años, y proporcionan un punto de partida para tus proyectos de software.

Note

Los patrones de diseño son guías que pueden ser adaptadas para cada propósito específico según se requiera.

Los patrones de diseño se dividen en tres categorías principales:

Patrones Creacionales: Estos patrones se relacionan con los procesos de creación de objetos. Su objetivo es abstraer los detalles de la instanciación de clases, haciendo los sistemas más independientes de cómo sus objetos son creados y representados. Dentro de esta categoría encontramos los patrones:
- Singleton
- Factory Method
- Abstract Factory
- Builder
- Prototype.
Patrones Estructurales: Estos patrones se enfocan en cómo las clases y objetos se componen para formar estructuras más grandes. Los patrones estructurales facilitan el diseño al identificar formas sencillas de realizar relaciones entre entidades. Dentro de esta categoría encontramos los patrones:
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy.
Patrones de Comportamiento: Estos patrones se centran en la comunicación entre objetos. Son útiles para definir patrones de comunicación entre clases y objetos, haciéndolos más flexibles y eficientes. Encontraremos patrones como:
- Observer [más info]
- Mediator
- Iterator
- Strategy [más info]
- Command
- State
- Visitor.

Cada patrón tiene su propio conjunto de reglas y contextos donde es más adecuado. Lo importante es entender que no existe un patrón que sea mejor que los otros en todas las situaciones.

Principios de diseño

Antes de adentrarte en los patrones de diseño, es buena idea tener unas bases y conceptos iniciales que te ayudarán al momento de estudiar cada uno de los patrones. Estos principios son:

Identifica los aspectos de tu aplicación que pueden cambiar y sepáralos de aquellos que probablemente seguirán igual.
Programa para una interfaz, no para una implementación. Programar para interfaces significa programar para supertipos.
Prefiere la composición sobre la herencia en OO. Es decir, si debes escoger entre una u otra, es más flexible y fácil implementar la composición, ya que esta se define a través de interfaces.
Esfuérzate por lograr diseños con acoplamientos débiles entre objetos que interactúan. Es decir, disminuye al máximo la dependencia entre los objetos de tu aplicación.
Las clases deben ser abiertas a código nuevo y cerradas a la modificación del mismo. Es decir, se debe evitar modificar lo existente siempre que sea posible.
Depende de abstracciones, no de clases concretas. Es decir, no utilices una clase como dependencia de otra; en su lugar, usa una clase abstracta o una interfaz

Qué No Hacer al Usar Patrones de Diseño

Al momento de estudiar y trabajar con los patrones de diseño, es importante tener en cuenta los siguientes puntos:

Conocer las bases de Orientación a Objetos (OO) no te hace un buen diseñador de OO.
Un buen diseño de OO es reutilizable, extensible y mantenible a lo largo del tiempo.
Los patrones te muestran cómo construir buenos sistemas usando cualidades de OO.
Los patrones son experiencias probadas orientadas a objetos.
Los patrones no te dan código; ellos te dan una solución general a problemas de diseño. Tu objetivo como programador e ingeniero de Software es aplicarlos y adaptarlos a tus casos específicos.
Los patrones no son inventados, son descubiertos. Tú podrías encontrar otro a lo largo de tu carrera.
La mayoría de los patrones y principios son capaces de manejar el constante cambio en el software, permitiéndote adaptar tu código a nuevos requerimientos sin grandes refactorizaciones.

Tip

No intentes aplicar todos los patrones de una vez. Empieza por entender el problema que resuelve cada uno y úsalos cuando el contexto lo requiera. La sobreingeniería es tan perjudicial como la falta de diseño.

Patrones De Diseño · DacaCode

Patrones de Diseño: Factory

Simple Factory

Factory Method

Abstract Factory

Factory Method vs Abstract Factory

Static Factory

Principio de Inversión de Dependencias

Consideraciones

Continúa la serie

Patrones de Diseño: Decorador

Objetivo del patrón decorador

Ejemplo de uso

Características del patrón decorador

Implementación del ejemplo en código

Teoría

Ejemplo

Consideraciones del patrón decorador

Patrones de Diseño: Observador

Teoría

Implementación

**Consideraciones del patrón observador**

Patrones de Diseño: Estrategia

Patrones de diseño: Qué son?

Principios de diseño

Qué No Hacer al Usar Patrones de Diseño

Consideraciones del patrón observador