Forem: Sadel Fortunato

Dia 8: 🧩 Abstract Factory Pattern en C#

Sadel Fortunato — Fri, 24 Oct 2025 23:18:26 +0000

¿QUÉ ES ABSTRACT FACTORY?
Es un patron para construir familia de objetos relacionados, esto nos permite crear una interfaz completa con todos los componentes que necesitemos. No necesitamos especificar la clase concreta.

Es un factory de factories

Analogía del Restaurant
Factory Method:
Restaurant → Crea solo HAMBURGUESAS

Hamburguesa clásica
Hamburguesa vegetariana
Hamburguesa premium Abstract Factory: Restaurant → Crea COMIDAS COMPLETAS
Entrada + Plato Principal + Postre (Menú Italiano)
Entrada + Plato Principal + Postre (Menú Mexicano)
Entrada + Plato Principal + Postre (Menú Japonés)

FACTORY METHOD (Un producto)
┌─────────────────────┐
│ TransporteFactory │
└─────────────────────┘
│
├─ Camión
├─ Barco
└─ Avión

ABSTRACT FACTORY (Familia de productos)
┌─────────────────────┐
│ UIFactory │
└─────────────────────┘
│
├─ WindowsFactory
│ ├─ Button
│ ├─ Window
│ └─ Checkbox
│
├─ MacFactory
│ ├─ Button
│ ├─ Window
│ └─ Checkbox
│
└─ LinuxFactory
├─ Button
├─ Window
└─ Checkbox

ESTRUCTURA DEL PATRÓN
Componentes:

AbstractFactory - Interfaz para crear familias de productos
ConcreteFactory - Implementación específica (ej: WindowsFactory)
AbstractProduct - Interfaz para un tipo de producto (ej: IButton)
ConcreteProduct - Implementación específica (ej: WindowsButton)
Client - Usa solo abstracciones, no clases concretas

Paso 1: Definir AbstractProducts

csharp// Productos abstractos (interfaces)
public interface IButton
{
    void Render();
    void Click();
}

public interface IWindow
{
    void Open();
    void Close();
    void Maximize();
}

public interface ICheckbox
{
    void Render();
    void Check();
    void Uncheck();
}

Paso 2: Crear ConcreteProducts para cada familia
csharp// ========== FAMILIA WINDOWS ==========
public class WindowsButton : IButton
{
    public void Render()
    {
        Console.WriteLine(" Renderizando botón estilo Windows");
    }

    public void Click()
    {
        Console.WriteLine(" Click en botón Windows");
    }
}

public class WindowsWindow : IWindow
{
    public void Open()
    {
        Console.WriteLine("🪟 Abriendo ventana Windows");
    }

    public void Close()
    {
        Console.WriteLine(" Cerrando ventana Windows");
    }

    public void Maximize()
    {
        Console.WriteLine(" Maximizando ventana Windows");
    }
}

public class WindowsCheckbox : ICheckbox
{
    public void Render()
    {
        Console.WriteLine(" Renderizando checkbox Windows");
    }

    public void Check()
    {
        Console.WriteLine(" Checkbox marcado");
    }

    public void Uncheck()
    {
        Console.WriteLine(" Checkbox desmarcado");
    }
}

// ========== FAMILIA MAC ==========
public class MacButton : IButton
{
    public void Render()
    {
        Console.WriteLine(" Renderizando botón estilo Mac");
    }

    public void Click()
    {
        Console.WriteLine(" Click en botón Mac");
    }
}

public class MacWindow : IWindow
{
    public void Open()
    {
        Console.WriteLine("🪟 Abriendo ventana Mac");
    }

    public void Close()
    {
        Console.WriteLine(" Cerrando ventana Mac");
    }

    public void Maximize()
    {
        Console.WriteLine(" Maximizando ventana Mac");
    }
}

public class MacCheckbox : ICheckbox
{
    public void Render()
    {
        Console.WriteLine(" Renderizando checkbox Mac");
    }

    public void Check()
    {
        Console.WriteLine(" Checkbox marcado (estilo Mac)");
    }

    public void Uncheck()
    {
        Console.WriteLine(" Checkbox desmarcado (estilo Mac)");
    }
}

Paso 3: Definir AbstractFactory
csharp// Factory abstracta
public interface IUIFactory
{
    IButton CreateButton();
    IWindow CreateWindow();
    ICheckbox CreateCheckbox();
}
Paso 4: Crear ConcreteFactories
csharp// Factory concreta para Windows
public class WindowsFactory : IUIFactory
{
    public IButton CreateButton()
    {
        return new WindowsButton();
    }

    public IWindow CreateWindow()
    {
        return new WindowsWindow();
    }

    public ICheckbox CreateCheckbox()
    {
        return new WindowsCheckbox();
    }
}

// Factory concreta para Mac
public class MacFactory : IUIFactory
{
    public IButton CreateButton()
    {
        return new MacButton();
    }

    public IWindow CreateWindow()
    {
        return new MacWindow();
    }

    public ICheckbox CreateCheckbox()
    {
        return new MacCheckbox();
    }
}

// Factory concreta para Linux
public class LinuxFactory : IUIFactory
{
    public IButton CreateButton()
    {
        return new LinuxButton();
    }

    public IWindow CreateWindow()
    {
        return new LinuxWindow();
    }

    public ICheckbox CreateCheckbox()
    {
        return new LinuxCheckbox();
    }
}
Paso 5: Cliente que usa la Factory
csharppublic class Aplicacion
{
    private IButton _button;
    private IWindow _window;
    private ICheckbox _checkbox;

    //  Cliente recibe factory, no sabe qué plataforma es
    public Aplicacion(IUIFactory factory)
    {
        _button = factory.CreateButton();
        _window = factory.CreateWindow();
        _checkbox = factory.CreateCheckbox();
    }

    public void Ejecutar()
    {
        _window.Open();
        _button.Render();
        _button.Click();
        _checkbox.Render();
        _checkbox.Check();
        _window.Maximize();
    }
}

// Uso
var platform = DetectarPlataforma(); // "Windows", "Mac", "Linux"

IUIFactory factory = platform switch
{
    "Windows" => new WindowsFactory(),
    "Mac" => new MacFactory(),
    "Linux" => new LinuxFactory(),
    _ => throw new PlatformNotSupportedException()
};

var app = new Aplicacion(factory);
app.Ejecutar();

PARTE 7: CUÁNDO USAR ABSTRACT FACTORY
Usa Abstract Factory cuando:

Necesitas familias de objetos relacionados

UI: Botón + Ventana + Menú para cada plataforma
Temas: Colores + Fuentes + Iconos para cada tema

Los objetos deben ser compatibles entre sí

No puedes mezclar botón de Windows con ventana de Mac
Todos deben ser de la misma familia

Quieres ocultar las implementaciones concretas

Cliente solo ve interfaces
No conoce las clases concretas

Quieres cambiar toda la familia fácilmente

De tema claro a oscuro
De MySQL a PostgreSQL

Tienes múltiples variantes de múltiples productos

3 plataformas × 5 componentes = 15 clases
Necesitas organización

NO uses Abstract Factory cuando:

Solo tienes un tipo de producto

Usa Factory Method

Las familias no son compatibles entre sí

Los objetos son independientes

No hay variaciones de familias

Solo una plataforma, un tema, etc.

Agregarás nuevos productos frecuentemente

Modificarás la interfaz abstracta constantemente

PARTE 8: VENTAJAS Y DESVENTAJAS
Ventajas:

Garantiza compatibilidad

Todos los productos son de la misma familia

Aislamiento de clases concretas

Cliente usa interfaces

Fácil cambiar familias

Solo cambias el factory

Single Responsibility

Creación centralizada

Open/Closed

Nuevas familias sin modificar cliente

Desventajas:

Complejidad

Muchas interfaces y clases

Difícil agregar nuevos productos

Debes modificar la interfaz AbstractFactory
Todas las factories concretas

Rigidez

La estructura está definida desde el inicio

Overkill para casos simples

Factory Method puede ser suficiente

Dia 7: 🧩 Factory Method Pattern en C#

Sadel Fortunato — Wed, 15 Oct 2025 09:59:49 +0000

Patrón Factory Method

Definición

El Factory Method es un patrón de diseño creacional que permite crear objetos sin conocer su clase concreta. En lugar de instanciar directamente un objeto con new, el patrón delega la responsabilidad de creación a un método especializado (el factory), el cual decide qué tipo de objeto instanciar según el contexto o las necesidades del cliente.

En otras palabras:

En vez de crear objetos directamente (new MiClase()), se utiliza un método factory que se encarga de devolver la instancia apropiada.
La lógica de creación queda centralizada y desacoplada del código cliente.

El Problema que Resuelve

Código acoplado:

// El cliente decide qué crear
if (tipo == "perro")
    var animal = new Perro();
else if (tipo == "gato")
    var animal = new Gato();

// Código repetido en muchos lugares
// Difícil de mantener y extender

En este enfoque, la lógica de creación está dispersa en distintas partes del sistema. Si se desea agregar un nuevo tipo o cambiar la forma en que se crean los objetos, será necesario modificar el código en múltiples lugares.

Solución con Factory Method:

// La fábrica decide qué crear
var animal = AnimalFactory.Crear(tipo);

// Lógica de creación centralizada
// Fácil de mantener y extender

Estructura del Patrón

Componentes Principales

Product (Producto): Define la interfaz común para todos los objetos que la fábrica puede crear.
ConcreteProduct (Producto Concreto): Implementaciones específicas del producto.
Creator (Creador): Declara el método fábrica que devolverá objetos del tipo producto.
ConcreteCreator (Creador Concreto): Implementa el método fábrica y determina qué producto concreto instanciar.

Ejemplo Práctico

1. Interfaz común (Product):

public interface INotificacion
{
    void Enviar(string mensaje);
}

2. Productos concretos:

public class NotificacionEmail : INotificacion
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"Email enviado: {mensaje}");
    }
}

public class NotificacionSMS : INotificacion
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"SMS enviado: {mensaje}");
    }
}

public class NotificacionPush : INotificacion
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"Push enviado: {mensaje}");
    }
}

3. Clase Factory:

public class NotificacionFactory
{
    public static INotificacion Crear(string tipo)
    {
        return tipo.ToLower() switch
        {
            "email" => new NotificacionEmail(),
            "sms" => new NotificacionSMS(),
            "push" => new NotificacionPush(),
            _ => throw new ArgumentException($"Tipo '{tipo}' no soportado")
        };
    }
}

4. Uso del patrón:

var notificacionEmail = NotificacionFactory.Crear("email");
notificacionEmail.Enviar("¡Hola Mundo!");

var notificacionSMS = NotificacionFactory.Crear("sms");
notificacionSMS.Enviar("¡Hola por SMS!");

Con este enfoque, el cliente no conoce las clases concretas de las notificaciones, sino que simplemente solicita al factory el tipo que necesita.

Cuándo Usar Factory Method

Úsalo cuando:

No sabes de antemano qué tipo exacto de objeto necesitas crear.
La decisión depende de una configuración, entrada del usuario o datos externos.
Deseas centralizar la lógica de creación y evitar código duplicado.
La creación de los objetos es compleja (requiere validaciones, configuraciones o inicializaciones).
Quieres desacoplar el cliente de las clases concretas y cumplir con el principio OCP (Open/Closed), agregando nuevos tipos sin modificar el código existente.

No lo uses cuando:

La creación del objeto es simple (un new MiClase() es suficiente).
Solo existe un tipo de objeto posible.
El tipo no cambiará y no hay lógica condicional en su creación.

Conclusión

El Factory Method es un patrón muy útil para desacoplar la creación de objetos y centralizar la lógica de instanciación.

Al aplicarlo, se cumplen varios principios SOLID, especialmente:

Single Responsibility (SRP): La creación de objetos se delega a una clase especializada.
Open/Closed (OCP): Se pueden agregar nuevos tipos sin modificar el código existente.
Dependency Inversion (DIP): Las dependencias se manejan a través de abstracciones y no de implementaciones concretas.

En resumen, este patrón proporciona una forma flexible, escalable y mantenible de crear objetos, permitiendo que el sistema evolucione sin afectar su estabilidad.

Dia 6: 🧩 Principio de Inversión de Dependencias (DIP) en C#

Sadel Fortunato — Tue, 14 Oct 2025 04:00:37 +0000

Principio de Inversión de Dependencias (DIP)
Definición

El Principio de Inversión de Dependencias establece que:

“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 los detalles. Los detalles deben depender de las abstracciones.”
— Robert C. Martin (Uncle Bob)

En términos simples:

No dependas de clases concretas.

Depende de interfaces o abstracciones.

Inyecta las dependencias desde afuera.

Invierte la dirección de las dependencias.

Analogía del Enchufe
Sin el Principio (acoplamiento directo)

Imagina una laptop cuyo cable de corriente está soldado internamente:

Si el cable se daña, debe reemplazarse toda la laptop.

No permite usar diferentes voltajes.

Es difícil de adaptar para otros países.

Con el Principio (desacoplamiento)

Ahora imagina una laptop con un puerto estándar:

Permite conectar diferentes cables.

Cambiar el cable no afecta a la laptop.

Puede funcionar en cualquier país usando un adaptador adecuado.

Conclusión:
El puerto representa la abstracción y los cables son las implementaciones. La laptop no depende de un cable específico, sino de un estándar.

El Problema: Dependencia Directa
Ejemplo
// Clase de bajo nivel (detalle concreto)

public class EmailService
{
    public void EnviarEmail(string mensaje)
    {
        Console.WriteLine($"Enviando email: {mensaje}");
    }
}

// Clase de alto nivel dependiente de una clase concreta

public class NotificacionService
{
    private EmailService _emailService = new EmailService();

    public void Notificar(string mensaje)
    {
        _emailService.EnviarEmail(mensaje);
    }
}

// Uso del sistema

var notificador = new NotificacionService();
notificador.Notificar("Hola mundo"); // Solo puede enviar emails

Problemas

Acoplamiento fuerte: NotificacionService depende directamente de EmailService.

Difícil de extender: No puede usarse SMS u otro canal sin modificar la clase.

Difícil de testear: No se pueden simular dependencias fácilmente.

Viola el Principio Abierto/Cerrado: No está cerrada a modificaciones.

La Solución: Inversión de Dependencias
Paso 1: Crear una Abstracción

public interface INotificacion
{
    void Enviar(string mensaje);
}

Paso 2: Implementar las Clases Concretas

public class EmailService : INotificacion
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"Email enviado: {mensaje}");
    }
}

public class SMSService : INotificacion
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"SMS enviado: {mensaje}");
    }
}

public class WhatsAppService : INotificacion
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"WhatsApp enviado: {mensaje}");
    }
}

Paso 3: Inyectar la Dependencia

public class NotificacionService
{
    private readonly INotificacion _canal;

    // Inyección de dependencia por constructor
    public NotificacionService(INotificacion canal)
    {
        _canal = canal;
    }

    public void Notificar(string mensaje)
    {
        _canal.Enviar(mensaje);
    }
}

Paso 4: Uso del Sistema

var notificadorEmail = new NotificacionService(new EmailService());
notificadorEmail.Notificar("Hola por Email");

var notificadorSMS = new NotificacionService(new SMSService());
notificadorSMS.Notificar("Hola por SMS");

var notificadorWhatsApp = new NotificacionService(new WhatsAppService());
notificadorWhatsApp.Notificar("Hola por WhatsApp");

Ventaja principal:
El comportamiento puede cambiarse sin modificar la clase NotificacionService. Solo se inyecta una nueva implementación de la interfaz.

Tipos de Inyección de Dependencias

Inyección por Constructor (recomendada)

public class ServicioUsuario
{
    private readonly IRepositorio _repositorio;

    public ServicioUsuario(IRepositorio repositorio)
    {
        _repositorio = repositorio ?? throw new ArgumentNullException();
    }
}

Ventajas:

Las dependencias son obligatorias desde la creación del objeto.

Las propiedades pueden mantenerse inmutables (readonly).

Facilita la realización de pruebas unitarias (mocking).

Mejora la claridad del código al mostrar explícitamente qué necesita la clase.

Dia 5: 🧩 Principio de Segregación de Interfaces (ISP) en C#

Sadel Fortunato — Mon, 13 Oct 2025 03:24:18 +0000

Principio de Segregación de Interfaces (ISP)

¿Qué dice este principio?

El Principio de Segregación de Interfaces (ISP) establece que los clientes no deben estar obligados a depender de servicios que no utilizan.
En otras palabras, se debe dividir la funcionalidad en interfaces más específicas y coherentes, de modo que cada cliente solo implemente o utilice los métodos que realmente necesita.

¿En qué nos beneficia?

Creamos interfaces más específicas y fáciles de entender.
Evitamos que los clientes trabajen con recursos innecesarios.
Probamos únicamente lo necesario, reduciendo complejidad en los tests.
Ganamos flexibilidad y capacidad de reutilización de métodos y componentes.

¿Qué problemas causa no aplicarlo?

Los clientes deben manejar o condicionar métodos que no usan.
Se crean controles innecesarios dentro del código.
Aumenta la cantidad de código repetido o sin propósito claro.
Se genera una interfaz demasiado grande y poco coherente, difícil de mantener.

Analogía: el restaurante

Imagina un restaurante donde un solo empleado debe:

Cocinar
Limpiar
Atender a los clientes
Servir las mesas

Esto genera problemas evidentes:

El chef no debería hacer entregas a domicilio.
El mesero no debería cocinar.
El cajero no necesita lavar platos.

Solución:
Dividir las responsabilidades según el rol de cada empleado:

ICocinero para cocinar
IConserje para limpiar
ICajero para cobrar

De esta forma, cada persona cumple su función sin verse obligada a realizar tareas innecesarias. Incluso podríamos tener un empleado multifuncional, como un aguatero que además pueda cobrar, simplemente implementando ambas interfaces según sea necesario.

El problema clásico: la impresora

Escenario:
En una oficina existen distintos dispositivos:

Una impresora simple (solo imprime)
Una impresora multifuncional (imprime, escanea y envía fax)
Una máquina de fax (solo envía fax)

Ejemplo incorrecto:

//  Interfaz demasiado grande: obliga a implementar todo
public interface IDispositivoOficina
{
    void Imprimir(string documento);
    void Escanear(string documento);
    void EnviarFax(string documento);
    void Fotocopiar(string documento);
}

//  ImpresoraSimple se ve OBLIGADA a implementar métodos que no usa
public class ImpresoraSimple : IDispositivoOficina
{
    public void Imprimir(string documento)
    {
        Console.WriteLine($"Imprimiendo: {documento}");
    }

    // Implementaciones innecesarias o con errores
    public void Escanear(string documento)
    {
        throw new NotSupportedException("Esta impresora no escanea");
    }

    public void EnviarFax(string documento)
    {
        throw new NotSupportedException("Esta impresora no tiene fax");
    }

    public void Fotocopiar(string documento)
    {
        throw new NotSupportedException("Esta impresora no fotocopia");
    }
}

//  El cliente que solo necesita imprimir depende de toda la interfaz
public class ServicioImpresion
{
    private IDispositivoOficina _dispositivo;

    public ServicioImpresion(IDispositivoOficina dispositivo)
    {
        _dispositivo = dispositivo;
    }

    public void ImprimirDocumento(string doc)
    {
        _dispositivo.Imprimir(doc);
    }
}

¿Por qué esto está mal?

Solemos crear clases que abarcan más de lo necesario, pensando en cubrir todas las posibles funcionalidades desde el inicio. Sin embargo, cuando otros clientes tienen necesidades similares pero no idénticas, terminamos forzando implementaciones innecesarias o poco limpias para poder cumplir con el contrato.

Problemas principales:

La clase ImpresoraSimple implementa métodos que no necesita.
El cliente depende de métodos que nunca utilizará.
Se genera código frágil, con excepciones innecesarias.
Es difícil de mantener y extender en el tiempo.

Solución correcta

La solución es dividir la interfaz en varias más pequeñas y específicas:

public interface IImpresora
{
    void Imprimir(string documento);
}

public interface IEscáner
{
    void Escanear(string documento);
}

public interface IFax
{
    void EnviarFax(string documento);
}

public interface IFotocopiadora
{
    void Fotocopiar(string documento);
}

//  Cada clase implementa solo lo que necesita
public class ImpresoraSimple : IImpresora
{
    public void Imprimir(string documento)
    {
        Console.WriteLine($"Imprimiendo: {documento}");
    }
}

public class ImpresoraMultifuncional : IImpresora, IEscáner, IFax, IFotocopiadora
{
    public void Imprimir(string documento) => Console.WriteLine($"Imprimiendo: {documento}");
    public void Escanear(string documento) => Console.WriteLine($"Escaneando: {documento}");
    public void EnviarFax(string documento) => Console.WriteLine($"Enviando fax: {documento}");
    public void Fotocopiar(string documento) => Console.WriteLine($"Fotocopiando: {documento}");
}

Ahora cada cliente utiliza únicamente la interfaz que necesita, y el código es más claro, mantenible y escalable.

Conclusión

El Principio de Segregación de Interfaces es una herramienta poderosa para mantener un código limpio, modular y adaptable.
Permite organizar mejor las implementaciones, evitando dependencias innecesarias y mejorando la reutilización de componentes.

Aunque su impacto puede parecer mínimo en proyectos pequeños, en sistemas grandes y complejos su aplicación marca una diferencia significativa, haciendo el código más estable, flexible y fácil de evolucionar.

Dia 4: 🧩 Principio de Sustitución de Liskov (LSP) en C#

Sadel Fortunato — Sat, 11 Oct 2025 23:11:00 +0000

Principio de Sustitución de Liskov (LSP)
¿Qué explica este principio?

El Principio de Sustitución de Liskov establece que una subclase debe poder reemplazar a su clase base sin afectar el correcto funcionamiento del programa.

En otras palabras:
Si tienes una clase llamada Ave y creas una subclase Pato, esta última debe poder ser utilizada en cualquier lugar donde se espere una Ave, sin alterar el comportamiento esperado del sistema.

Esto significa que las subclases deben cumplir con el contrato definido por la clase base.
Las condiciones previas no deben hacerse más estrictas.
Las condiciones posteriores no deben debilitarse.

¿Qué beneficios obtenemos al aplicarlo?

Se logra un verdadero polimorfismo: las subclases pueden comportarse como la clase base sin problemas.
El código se vuelve más fácil de probar y mantener.
El desarrollo es más predecible y coherente respecto al contrato de la clase base.

Programación vs Matemáticas

Un ejemplo sencillo pero fundamental para comprender este principio es el caso del cuadrado y el rectángulo.

Ambas figuras comparten ciertos requisitos: tienen cuatro lados. Sin embargo, no cumplen las mismas condiciones geométricas.

Un cuadrado requiere cuatro lados iguales.
Un rectángulo necesita lados con diferente anchura y altura.

En la práctica, no es correcto heredar Square de Rectangle, porque estaríamos forzando comportamientos que rompen las reglas de una u otra figura. Si lo hacemos, estaremos sobrecargando la clase base y rompiendo el principio de Liskov.

// Clase base: Rectángulo
public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }

    public int CalculateArea()
    {
        return Width * Height;
    }
}

// VIOLACIÓN LSP: Cuadrado hereda de Rectángulo
public class Square : Rectangle
{
    private int _side;

    public override int Width
    {
        get => _side;
        set => _side = value;
    }

    public override int Height
    {
        get => _side;
        set => _side = value;
    }
}

// PROBLEMA: Este código FALLA
public void TestRectangle(Rectangle rect)
{
    rect.Width = 5;
    rect.Height = 10;

    // Esperamos: 5 * 10 = 50
    // Con Rectangle: 50
    // Con Square: 100 (ambos lados cambian al último valor: 10)

    Console.WriteLine($"Área: {rect.CalculateArea()}");
}

Problemas detectados:

No deberíamos heredar de una clase que ya cumple una función solo porque parece “similar”.
Tenemos que manipular propiedades para intentar obtener un resultado esperado.
El cuadrado no puede adaptarse correctamente al comportamiento del rectángulo.

Solución correcta

En lugar de forzar una relación de herencia, debemos usar una interfaz común que defina el contrato general para todas las figuras:

// Interfaz común
public interface IShape
{
    int CalculateArea();
    string GetDescription();
}

// Rectángulo implementa IShape
public class Rectangle : IShape
{
    public int Width { get; set; }
    public int Height { get; set; }

    public int CalculateArea() => Width * Height;
    public string GetDescription() => $"Rectángulo: {Width}x{Height}";
}

// Cuadrado implementa IShape (NO hereda de Rectangle)
public class Square : IShape
{
    public int Side { get; set; }

    public int CalculateArea() => Side * Side;
    public string GetDescription() => $"Cuadrado: {Side}x{Side}";
}

// FUNCIONA: Ambos son IShape pero sin herencia problemática
public void ProcessShape(IShape shape)
{
    Console.WriteLine(shape.GetDescription());
    Console.WriteLine($"Área: {shape.CalculateArea()}");
}

¿Qué logramos?

Una interfaz flexible ante nuevos requerimientos.
Se aplica el principio de responsabilidad única (SRP): cada clase representa correctamente su figura.
La interfaz IShape está abierta a la extensión y cerrada a la modificación, cumpliendo también con el principio Open/Closed.
Fácil de probar y extender con nuevas figuras en el futuro.
No fortalecemos condiciones previas ni debilitamos las posteriores: mantenemos un contrato coherente y estable.

Conclusión

El Principio de Sustitución de Liskov es esencial cuando se crean variantes de un objeto con comportamientos o reglas diferentes, pero que comparten un mismo propósito general.

Por ejemplo, en un sistema de reportes, las operaciones de guardar, leer y exportar son comunes. Si queremos exportar diferentes tipos de documentos, lo ideal es definir una interfaz con estas funcionalidades y luego crear implementaciones específicas para cada tipo de reporte.

Así logramos un diseño extensible, predecible y fácil de mantener, evitando la fragilidad de las herencias mal aplicadas y garantizando un verdadero polimorfismo.

Dia 3: 🧩 Principio Abierto/Cerrado (Open/Closed Principle) en C#

Sadel Fortunato — Fri, 10 Oct 2025 04:01:42 +0000

¿Qué es el Principio Abierto/Cerrado?

El Principio Abierto/Cerrado (Open/Closed Principle) establece que:

Las clases deben estar abiertas para su extensión, pero cerradas para su modificación.

Esto significa que deberíamos poder agregar nuevas funcionalidades sin modificar el código existente.
El objetivo es evitar romper el comportamiento actual del sistema cuando se introducen cambios.

Ejemplo de la vida real

Piensa en un enchufe eléctrico.
No cambiamos el enchufe de la pared cada vez que aparece un nuevo dispositivo.
Simplemente los dispositivos se adaptan al enchufe.

De igual forma, nuestro código debe estar diseñado para adaptar nuevas extensiones sin tocar el código ya probado y estable.

Ejemplo que viola el principio

Veamos una clase Notificador que no cumple el principio:

public class Notificador
{
    public void Enviar(string tipo, string mensaje)
    {
        if (tipo == "email")
        {
            Console.WriteLine($"Email: {mensaje}");
        }
        else if (tipo == "sms")
        {
            Console.WriteLine($"SMS: {mensaje}");
        }
        else if (tipo == "push") // ← MODIFICAMOS la clase
        {
            Console.WriteLine($"Push: {mensaje}");
        }
        else if (tipo == "slack") // ← MODIFICAMOS nuevamente
        {
            Console.WriteLine($"Slack: {mensaje}");
        }

        // ¿WhatsApp? ¿Discord? ¿Telegram?
        // ¡Seguiremos modificando esta clase!
    }
}

Problemas con este enfoque

Cada vez que se agrega un nuevo tipo de notificación, tenemos que modificar la clase.
Difícil de testear y mantener.
Rompe el Principio de Responsabilidad Única (SRP).
El código puede crecer fácilmente hasta tener cientos de líneas solo en un método.

Solución aplicando el Principio Abierto/Cerrado

Interfaz base (cerrada para modificación)

public interface INotificador
{
    void Enviar(string mensaje);
}

Implementaciones (abiertas para extensión)

public class NotificadorEmail : INotificador
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"Email: {mensaje}");
    }
}

public class NotificadorSMS : INotificador
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"SMS: {mensaje}");
    }
}

public class NotificadorPush : INotificador
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"Push: {mensaje}");
    }
}

Agregar una nueva notificación (ejemplo: Slack)

public class NotificadorSlack : INotificador
{
    public void Enviar(string mensaje)
    {
        Console.WriteLine($"Slack: {mensaje}");
    }
}

*Clase gestora que usa la interfaz *

public class GestorNotificaciones
{
    private readonly INotificador _notificador;

    public GestorNotificaciones(INotificador notificador)
    {
        _notificador = notificador;
    }

    public void Notificar(string mensaje)
    {
        _notificador.Enviar(mensaje);
    }
}

Uso del código

class Program
{
    static void Main()
    {
        INotificador notificador = new NotificadorSlack();
        var gestor = new GestorNotificaciones(notificador);

        gestor.Notificar("¡Hola desde Slack!");
    }
}

¿Qué logramos con esto?

Ahora cada tipo de notificación es independiente.
Si queremos agregar un nuevo canal, como WhatsApp o Telegram, solo creamos una nueva clase que implemente INotificador.

No necesitamos modificar las clases existentes

Beneficios

Fácil de testear: cada clase puede probarse de forma aislada.
Cumple el Principio de Responsabilidad Única (SRP).
Código limpio, legible y mantenible.
Escalable: agregar nuevas notificaciones es sencillo.

Conclusión
El Principio Abierto/Cerrado es una pieza fundamental de SOLID.
Te permite construir software flexible, mantenible y escalable a largo plazo.

Diseña tu código para extenderse, no para reescribirse.

DIA 2: PRINCIPIO DE RESPONSABILIDAD UNICA

Sadel Fortunato — Wed, 08 Oct 2025 17:08:59 +0000

¿Qué es el Principio de Responsabilidad Única?

"Una clase debe tener una sola razón para cambiar"

-Robert C. Martin.

De la forma sencilla se traduce como: cada clase o modulo debe tener una sola razón de ser u ocuparse de una sola cosa y hacerla bien.

¿Qué significa "una razón para cambiar"?

Una razón para cambiar significa que actores podrían solicitar campos, por ejemplo, Equipo de:

Ventas
Finanzas
Usuarios Finales
Equipo de seguridad
Etc.

Una analogía del mundo real sería EL RESTAURANTE:

Mesero que:

Toma ordenes
Sirve comida
Cobra
Limpia
Gestiona inventario

Esto destroza en su totalidad este principio, ya que sin muchas funciones delegas a una sola entidad.

podríamos tener:

Mesero: Solo toma órdenes y sirve
Chef: Solo cocina
Personal de limpieza: Limpia
Cajero: solo cobra
Gerente: Gestiona Inv.

Esto respeta totalmente el principio ya que cada actor o entidad está cumpliendo una única labor y está enfocada en cumplir bien esa labor

Beneficios:

Es más mantenible y gestionable
Pequeñas actividades tienen menor margen de error
La colaboración distribuida hace más reutilizable una entidad

`class Usuario:
def init(self, nombre, email, contraseña):
self.nombre = nombre
self.email = email
self.contraseña = contraseña

def validar_email(self):
    """Valida formato de email"""
    import re
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    return re.match(pattern, self.email) is not None

def encriptar_contraseña(self):
    """Encripta la contraseña"""
    import hashlib
    return hashlib.sha256(self.contraseña.encode()).hexdigest()

def guardar_en_base_datos(self):
    """Guarda usuario en BD"""
    import sqlite3
    conn = sqlite3.connect('usuarios.db')
    cursor = conn.cursor()
    cursor.execute(
        "INSERT INTO usuarios VALUES (?, ?, ?)",
        (self.nombre, self.email, self.encriptar_contraseña())
    )
    conn.commit()
    conn.close()

def enviar_email_bienvenida(self):
    """Envía email de bienvenida"""
    import smtplib
    msg = f"Bienvenido {self.nombre}!"
    # código para enviar email...
    print(f"Email enviado a {self.email}")

def generar_reporte_pdf(self):
    """Genera reporte PDF del usuario"""
    from reportlab.pdfgen import canvas
    # código para generar PDF...
    print(f"PDF generado para {self.nombre}")`

En este código tenemos la clase usuario que hace distintas actividades o mencionado en la analogía anterior del restaurante tenemos el actor usuario que está ejecutando distintas funciones, al igual que la primera representación del mesero.

Aquí podemos identificar que nuestro mesero (clase usuario)
tiene las siguientes actividades:

Gestionar datos del usuario
Validar datos del usuario
Manejar la contraseña del usuario
Notificaciones
Persistencia o Guardar en base de datos
Reportes

Razones para cambiar (Actores):

Que se cambie el proceso de notificación
Que modifiquemos el proveedor del email
Que los reportes tengan formatos distintos
Que cambiemos la encriptación de la contraseña
Que migremos la base de datos de SQLite a PostgreSQL

1. Clase Usuario: SOLO datos y lógica básica

class Usuario:
def init(self, nombre, email, contraseña):
self.nombre = nombre
self.email = email
self.contraseña = contraseña

def get_datos(self):
    return {
        'nombre': self.nombre,
        'email': self.email
    }

2. Validador: SOLO validación

class ValidadorEmail:
@staticmethod
def validar(email):
import re
pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$'
return re.match(pattern, email) is not None

3. Servicio de Seguridad: SOLO encriptación

class ServicioSeguridad:
@staticmethod
def encriptar_contraseña(contraseña):
import hashlib
return hashlib.sha256(contraseña.encode()).hexdigest()

4. Repositorio: SOLO persistencia

class RepositorioUsuario:
def init(self, conexion_bd):
self.conexion = conexion_bd

def guardar(self, usuario):
    cursor = self.conexion.cursor()
    contraseña_hash = ServicioSeguridad.encriptar_contraseña(usuario.contraseña)
    cursor.execute(
        "INSERT INTO usuarios VALUES (?, ?, ?)",
        (usuario.nombre, usuario.email, contraseña_hash)
    )
    self.conexion.commit()

def buscar_por_email(self, email):
    cursor = self.conexion.cursor()
    cursor.execute("SELECT * FROM usuarios WHERE email = ?", (email,))
    return cursor.fetchone()

5. Servicio de Email: SOLO notificaciones

class ServicioEmail:
def init(self, config_smtp):
self.config = config_smtp

def enviar_bienvenida(self, usuario):
    mensaje = f"¡Bienvenido {usuario.nombre}!"
    # Código real de envío de email
    print(f"Email enviado a {usuario.email}: {mensaje}")

6. Generador de Reportes: SOLO PDFs

class GeneradorReportesPDF:
def generar_reporte_usuario(self, usuario):
# Código para generar PDF
print(f"PDF generado para {usuario.nombre}")
return f"reporte_{usuario.nombre}.pdf"

USO:

def registrar_usuario(nombre, email, contraseña):
# Validar
if not ValidadorEmail.validar(email):
raise ValueError("Email inválido")

# Crear usuario
usuario = Usuario(nombre, email, contraseña)

# Guardar
import sqlite3
conn = sqlite3.connect('usuarios.db')
repo = RepositorioUsuario(conn)
repo.guardar(usuario)

# Notificar
servicio_email = ServicioEmail(config_smtp={})
servicio_email.enviar_bienvenida(usuario)

# Generar reporte
generador = GeneradorReportesPDF()
generador.generar_reporte_usuario(usuario)

conn.close()
return usuario

`
BENEFICIOS DE LA REFACTORIZACIÓN:

Usuarios: Solo se encarga de gestionar lo mínimo del usuario
ValidadorEmail: puedes reutilizarse en otros contextos
ServicioSeguridad:Fácil cambiar de SHA256 a bcrypt
El repositorio de usuario es fácil moverlo de DB
La reporteria puede ser reutilizable y flexible para cambiar de libreria
Facil de cambiar el proveedor de email

Ahora cada clase tiene una sola razon para cambiar