Principios de programación SOLID

El principio de responsabilidad única o Single Responsability Principle (también conocido como SRP) es uno de los cinco principios SOLID que ayuda a modelar código orientado a objetos de una manera más robusta y mantenible a la larga. El principio SRP nos dice que una clase sólo debe tener una única responsabilidad y por lo tanto una única razón para cambiar en el futuro. Es uno de los más fáciles de comprender pero en este vídeo proporciono un ejemplo que permita comprender cómo modelar un sistema orientado a objetos respetando este principio.

El principio abierto-cerrado u Open-Closed Principle (también conocido como OCP) es uno de los cinco principios SOLID que ayuda a modelar el código orientado a objetos de una manera más robusta y mantenible a la larga. El principio OCP dice que una clase debe estar abierta para su extensión, pero cerrada para su modificación. O sea, que una vez una clase ha sido desarrollada, cualquier futura extensión que sirva para cumplir un nuevo requisito o cambio en la aplicación debe ser desarrollado fuera de esa clase. Este es uno de los principios más confusos de comprender debido al nombre tan inteligente que tiene, pero tiene su mecánica.

El principio de sustitución de Liskov establece que las precondiciones, postcondiciones, invariantes y otras formalidades que se cumplen para una clase también se deben cumplir para sus clases derivadas. De este modo, las referencias a un tipo se pueden hacer respecto de la clase base, sin que otros módulos del sistema trabajen con subentidades concretas.

El principio de segregación de interfaz establece que los clientes de una interfaz no deben depender de métodos que no vayan a utilizar. O dicho en español: hay que hacer las interfaces más pequeñas y con menos métodos, en vez de tener interfaces grandes ("fat interfaces") que expongan métodos más variopintos que sólo sean interesantes para algunas situaciones.

El principio de inversión de dependencia establece que los módulos de alto nivel, cuando dependen de módulos de bajo nivel, deben hacerlo mediante abstracciones, como interfaces, en vez de depender directamente, de tal manera que una clase de alto nivel no esté acoplada con una implementación concreta de una faceta de la aplicación, sino con una interfaz que pueda ser aplicada por otras facetas compatibles.