Del curso: Fundamentos de la programación: Diseño orientado a objetos

Principios SOLID

Del curso: Fundamentos de la programación: Diseño orientado a objetos

Comenzar mi mes de prueba gratis Comprar para mi equipo

Principios SOLID

“

Otro tipo de principios que merece la pena evaluar son los principios SOLID. Presenta cinco principios básicos de la programación orientada a objetos, que, cuando se aplican, redundan en un código mucho más fácil de mantener, ampliar y leer. En primer lugar, el principio de responsabilidad única, o «Single responsibility», nos enuncia que un objeto debe tener una responsabilidad primordial, es decir, una razón para existir, y la razón debe estar completamente encapsulada dentro de una clase. Todos sus comportamientos deben orientarse en torno a esa razón fundamental, y todo lo que hace debe apoyar eso. Una de las consecuencias es no crear un objeto dios que tome demasiadas responsabilidades ni tampoco que nos obligue a dividir el comportamiento a través de múltiples objetos, porque, finalmente, un objeto siempre debe ser responsable de sí mismo. La O de SOLID se corresponde a «Open/closed principle», o principio de cierre y apertura, en el que el software debe estar abierto a la extensión, pero cerrado a la modificación. Esto se refiere a que una vez desarrollado el sistema, si es algo necesario agregar código, lo harás escribiendo código nuevo y no cambiando el código que ya funciona. La L es para el principio de sustitución de Liskov, o «Liskov substitution principle», que enuncia que las clases derivadas de un programa deben ser sustituibles por las clases base, y todo esto debe realizarse sin alterar la exactitud del programa. Es una extensión de la idea esencial de herencia. Lo que significa es que, si hemos creado un montón de subclases, siempre debo ser capaz de utilizar cualquiera de ellas y tratarla como su superclase sin afectar al resto. La penúltima, la I, corresponde a «Interface segregation principle», o principio de segregación de interfaces. Este nos guía enunciando que muchas interfaces de cliente específicas son mejores que una sola interfaz de propósito general. Por último, tenemos la D de «Dependency inversion principle», o principio de inversión de la dependencia. Esto implica que no debe apuntarse directamente a objetos concretos, sino que debemos crear objetos que hagan frente a las abstracciones con la finalidad de minimizar las dependencias en los objetos.

Contenido