Principios SOLID

2019-12-08 SOLID

El acrónimo SOLID, hace referencia a conjunto de principios mundialmente aceptados en el desarrollo orientado a objetos. Estos cinco principios, buscan que el código sea más entendible, flexible y mantenible. Estos principios fueron creado por Robert C. Martin en un paper del año 2000 llamado Design Principles and Design Patterns y hacen parte de un grupo más grande de principios y buenas prácticas promovidos por él. Cada letra del acrónimo hace referencia a un principio los cuáles veremos a continuación.

Single Responsability principle

El princpio de responsabilidad única hace rereferencia a que una clase solo debe tener un trabajo o responsabilidad. Esto visto de otra forma, significa que solo debe existir una razón para cambiar una clase. Las clases con muchas responsabilidades son difíciles de mantener.

Open Close principle

Este principio dice que las entidades (clases, métodos o funciones) deben estar abiertas para extensión pero cerradas para modificación. Que una entidad sea abierta para extensión, significa que es posible cambiar el comportamiento de dicha entidad. Por otro lado, que sea cerrada para modificación, implica que debe ser posible cambiar el comportamiento sin modificar el código fuente original.

Liskov Substitution principle

Este principio dice que los objetos de un programa pueden ser reemplazados por sus subtipos sin alterar el correcto funcionamiento del programa. Es decir, un argumento de una función o método que acepte una clase o interfaz, debería funcionar igual con cualquier subtipo de la misma clase o interfaz. Para que esto sea posible, es necesario que la signature de los métodos implementados o sobreescritos sean iguales y no agreguen o cambien el TIPO del resultado de la función (incluyendo excepciones).

Interface Segregation principle

Este principio dice que un cliente no debe forzar la implementación de una interfaz que no utiliza. Dicho de otra forma, muchas interfaces cliente específicas son mejores que una interfaz de propósito general. Si una método o función recibe una dependencia que implementa otros métodos que no son de su interés, debe realizarse una segregación y crear una interfaz específica.

Dependency Inversion principle

Este principio dice que las dependencias debes estar dadas por abstracciones y no por clases concretas. Es uno de los principios tal vez más difíciles de entender y hace referencia a desacoplar el código. Las funciones o métodos no deberían depender de clases concretas, ya que esto genera un acomplamiento con el código de bajo nivel implementado en dicha clase; en su lugar, las dependencias deben darse a alto nivel, es decir, con clases abstractas o interfaces.

Acerca de Darío Rivera

Author

Ingeniero de desarrollo en PlacetoPay , Medellín. Darío ha trabajado por más de 6 años en lenguajes de programación web especialmente en PHP. Creador del microframework DronePHP basado en Zend y Laravel.

Sólo aquellos que han alcanzado el éxito saben que siempre estuvo a un paso del momento en que pensaron renunciar.