Tiempo de lectura: 5 minutos

Principios SOLID en la programación orientada a objetos

Quién lleva años programando sabe que en el 99,99% de los casos los requisitos iniciales se ven alterados una vez ha comenzado el desarrollo e incluso ha terminado. Es más, seguramente la aplicación desarrollada evolucione constantemente.

Esto es una realidad que tenemos que asumir los programadores y tenemos que tenerlo muy en cuenta en nuestros desarrollos. Si nuestro jefe de proyecto asume el tiempo malgastado por no recoger bien los requisitos o si cliente asume ese error nosotros no tenemos por qué preparar ‘la tercera guerra mundial’ contra nuestro responsable. Esta serenidad antes los cambios es algo que se va ganando con los años de experiencia y aflora en aquellas personas que comienzan a desarrollar porque tienen (he tenido) el concepto de la ‘aplicación perfecta’ donde todas las funcionalidades se encuentran en un documento inalterable.

Estos cambios hay que verlos como un nuevo reto, como una nueva pieza a encajar en el puzzle que estamos desarrollando, el problema es que en la mayoría de las ocasiones, la encajamos a ‘puñetazos’.

Para que estos cambios constantes cuesten lo menos posibles, Robert C. Martín nos propuso en el año 2000 unos principios para que nuestro código orientado a objeto sea más flexible. Estos principios están recogidos sobre el acrónimo SOLID.

Seguramente habrás escuchado muchas veces la expresión ‘aplicaciones sólidas”, pues bien, lo de sólidas se refiere a que en el desarrollo se aplican estos principios.

SOLID describe cinco principios fundamentales, uno por cada letra, sobre el diseño orientado a objetos. Veamos que significan:

Single Responsability Principle o Principio de Responsabilidad Única

Este principio indica que una clase debe tener una única responsabilidad. O como nos indica Rober C. Martín: “Una clase debería tener una y sólo una razón para cambiar”. ¿Cuántas veces hemos creado una clase que hace de todo? por no hablar de la típica clase UtilsXXXX. Un ejemplo de esas clases que “hacen de todo” y que veo frecuentemente, es aquella que engloba una conexión a un web service, un parseador de objetos json a modelos y métodos para guardar esos objetos en base de datos, todo esto, es una misma clase. Aunque nos parezcan clases sencillas, clases pequeñas, una clase debería tener una única responsabilidad.

Open-Closed Principle o Principio de abierto-cerrado

Este principio fue acuñado por el Dr. Bertrand Meyer en su libro: “Object Oriented Software Construction”[1997]

Una entidad debe estar abierta a extensiones pero cerrada a modificaciones. Este principio va acorde con el principio anterior ya que como se ha indicado, una clase nunca debería cambiar y si un requisito cambia, lo que debemos hacer es extender dicho comportamiento añadiendo código, no modificándolo.

Con esto, también evitamos que clases que depende de otras sean modificadas y se extienda esa modificación.

Cuando se habla de extender la clase se puede usar varios métodos como la herencia o la inyección de dependencias.

Liskov Substitution Principle o Principio de Sustitución de Liskov

Este principio fue introducido por Barbara Liskov en el año 1987 y viene a decir que si una función recibe un objeto como parámetro, de tipo X y en su lugar le pasamos otro de tipo Y, que hereda de X, dicha función debe proceder correctamente. Este principio está muy ligado al anterior.

Interface Segregation Principle o Principio de Segregación de Interfaces

Su author fue Rober C. Martín. Este principio está muy unido al de responsabilidad única y viene a decir que los clientes no deben ser forzosamente dependientes de las interfaces que no utilizan o de otra forma, que las interfaces no sean tan pesadas que obliguen a las clases que las implementan a implementar métodos que no necesita.

Dependency Inversion Principle o Principio de Inversión de Dependencia

Rober C. Martín afirma en este principio:

  • Las clases de alto nivel no deberían depender de las clases de bajo nivel. Ambas deberían depender de las abstracciones.
  • Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.

La inversión de dependencia explica que una clase concreta A, no debe depender directamente de otra clase B, sino de una abstracción de B. Tal abstracción es una interfaz o una clase que sirce de base para un conjunto de clases hijas.

 

Bibliografía: