Los principios SOLID son un conjunto de cinco principios de diseño de software que ayudan a crear sistemas más mantenibles, escalables y flexibles(ver mas).
| Principio | Descripción | Clase que viola el principio | Clase que soluciona el principio |
|---|---|---|---|
| SRP | Una clase debe tener una sola razón para cambiar | Employee | EmployeeRepository, PayrollService |
| OCP | Una clase debe estar abierta para su extensión pero cerrada para su modificación | PaymentGateway | PaymentProcessor, CreditCardPaymentProcessor, PayPalPaymentProcessor |
| LSP | Las clases derivadas deben ser sustituibles por sus clases base | Bird | FlyingBird, Eagle |
| ISP | Una clase no debe ser forzada a implementar una interfaz que no utiliza | Printer | Printable, Scannable, Photocopier |
| DIP | Las clases de alto nivel no deben depender de las clases de bajo nivel, ambas deben depender de abstracciones | Car | CarFactory |
La clase Employee viola el principio SRP porque tiene más de una razón para cambiar (guardar en base de datos y imprimir nómina). Las clases EmployeeRepository y PayrollService solucionan este principio al separar las responsabilidades.
La clase PaymentGateway viola el principio OCP porque no está abierta para su extensión (no se puede agregar un nuevo tipo de pago sin modificar la clase). Las clases PaymentProcessor, CreditCardPaymentProcessor y PayPalPaymentProcessor solucionan este principio al crear una jerarquía de clases que permite agregar nuevos tipos de pago sin modificar la clase base.
La clase Bird viola el principio LSP porque no se puede sustituir por sus clases derivadas (no todos los pájaros pueden volar). Las clases FlyingBird y Eagle solucionan este principio al crear una jerarquía de clases que permite sustituir las clases derivadas por sus clases base.
La clase Printer viola el principio ISP porque fuerza a implementar una interfaz que no utiliza (no todos los impresores pueden escanear). Las clases Printable, Scannable y Photocopier solucionan este principio al crear interfaces separadas para cada funcionalidad.
La clase Car viola el principio DIP porque depende de una clase de bajo nivel (GasolineEngine). Las clases Engine y CarFactory solucionan este principio al crear una abstracción que permite cambiar el tipo de motor sin modificar la clase Car.