Scribd
Cargar
14 vistas2 páginas

EjemplosPracticos SOLID

Los principios SOLID son directrices de diseño orientado a objetos que promueven la creación de software mantenible y flexible. Se presentan ejemplos en C# que ilustran cada principio: SRP, OCP, LSP, ISP y DIP, mostrando tanto implementaciones deficientes como mejores prácticas. Estos principios ayudan a evitar problemas comunes en el desarrollo de software al fomentar la separación de responsabilidades y la dependencia de abstracciones.

Cargado por

marianosandoval846
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
14 vistas2 páginas

EjemplosPracticos SOLID

Los principios SOLID son directrices de diseño orientado a objetos que promueven la creación de software mantenible y flexible. Se presentan ejemplos en C# que ilustran cada principio: SRP, OCP, LSP, ISP y DIP, mostrando tanto implementaciones deficientes como mejores prácticas. Estos principios ayudan a evitar problemas comunes en el desarrollo de software al fomentar la separación de responsabilidades y la dependencia de abstracciones.

Cargado por

marianosandoval846
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

Ejemplos Prácticos de los Principios

SOLID
Los principios SOLID son un conjunto de buenas prácticas de diseño orientado a objetos que
ayudan a crear software más mantenible, escalable y flexible. A continuación, se presentan
ejemplos prácticos en C# para cada principio.

S — Single Responsibility Principle (SRP)


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

Ejemplo malo:
public class Reporte {
public string GenerarPDF(string contenido) {...}
public void EnviarPorCorreo(string contenido, string email) {...}
}
Aquí la clase hace dos cosas: generar y enviar.

Ejemplo bueno:
public class GeneradorReporte {...}
public class ServicioCorreo {...}
Cada clase tiene su propia responsabilidad.

O — Open/Closed Principle (OCP)


Las clases deben estar abiertas a extensión pero cerradas a modificación.

Ejemplo malo:
public decimal Calcular(decimal precio, string tipoCliente) {
if (tipoCliente=="VIP") ...
}
Se debe modificar cada vez que hay un nuevo tipo.

Ejemplo bueno:
public interface IDescuento {...}
public class DescuentoVIP : IDescuento {...}
public class CalculadoraDescuento {...}
Se agregan nuevos descuentos sin modificar la calculadora.
L — Liskov Substitution Principle (LSP)
Las subclases deben poder reemplazar a las clases base sin alterar el comportamiento.

Ejemplo malo:
public class Ave { public virtual void Volar() {...} }
public class Pinguino : Ave { public override void Volar() { throw ... } }
Esto rompe el principio.

Ejemplo bueno:
public abstract class Ave {...}
public class AveVoladora : Ave {...}
public class Pinguino : Ave {...}
Cada subclase tiene métodos que sí aplica.

I — Interface Segregation Principle (ISP)


No obligar a implementar métodos que no se usan.

Ejemplo malo:
public interface IMultifuncional { void Imprimir(); void Escanear(); void Fax(); }
Una impresora básica no debería implementar métodos que no usa.

Ejemplo bueno:
public interface IImpresora {...}
public interface IEscaner {...}
public interface IFax {...}
Cada clase implementa solo lo necesario.

D — Dependency Inversion Principle (DIP)


Las clases deben depender de abstracciones y no de implementaciones concretas.

Ejemplo malo:
public class ServicioNotificacion { private Correo _correo = new Correo(); }
Depende directamente de una clase concreta.

Ejemplo bueno:
public interface INotificador {...}
public class Correo : INotificador {...}
public class SMS : INotificador {...}
public class ServicioNotificacion { private INotificador _notificador; ... }
Se puede cambiar el canal sin modificar la clase.

También podría gustarte