S.O.L.I.D: Aplicables a proyectos de desarrollo de software

Para nadie es un secreto que desarrollar aplicaciones de software con calidad, es importante en la creación de todo producto. Por tanto, no basta con indicar que un producto es funcionalmente correcto sólo porque da cumplimento a lo que inmediatamente se quiere resolver o sólo porque da solución a un problema en particular.

La experiencia nos ha enseñado que no podemos pensar en aplicaciones que no se puedan escalar o ampliar en funcionalidad y comportamiento, dado que el mundo está en constante evolución y para ello dichas aplicaciones deberían adaptarse al cambio en general. Recordemos que las aplicaciones de software de hoy en día, resuelven problemas de la humanidad, por tanto, si esta última cambia, también se tendrá que adaptar nuestras aplicaciones y para ello se debe estar sujetos a cambios y en como efecto se logrará una evolución continua.

Existen ciertos estándares que aseguran que dichos cambios sean fáciles de implementar y que además de ello, permiten que nuestras aplicaciones cumplan con la calidad requerida, generando así un efecto de prevalencia en el tiempo y asegurando además que su manteniendo sea mucho más fácil y efectivo.

https://lh3.googleusercontent.com/-PCjRWNDJwxA/W_a_AlkdEsI/AAAAAAAAAD8/IGTUBiW3l346shmSBFdSqU_FjsBaLscVACL0BGAYYCw/h242/Imagen1.png

Fig. 1. Evolución de un sistema de software

En la mayor parte de la teoría de ingeniería del software, se mencionan estándares de calidad que aseguran la correctitud del comportamiento de las aplicaciones, y como ya lo mencionamos antes, permite que la aplicación software sea más fácil de mantener. Antes de entrar en detalle, tomate el trabajo de realizar un análisis de las aplicaciones que has desarrollado hasta el momento a lo largo de tu experiencia en todo lo relacionado a la programación orientada a objetos.

Una vez hecho esto y sin más preámbulo en este post, miraremos los cinco principios básicos en POO y el diseño, denominado SOLID, por su acrónimo en inglés introducido por el ingeniero Robert C. Martin a comienzos del año 2000 y miremos si estos principios los estás aplicando correctamente en tus proyectos. Ya que por medio de la aplicación de estos cinco principios se asegura la facilidad para realizar mantenimiento al software, así como su ampliación en el tiempo.

De esta manera SOLID, nos permite realizar una limpieza a nuestro código, generando un código legible, refactorizable, fácil de entender y de extender. Estos principios son muy utilizados en el desarrollo ágil, pues permite además su fácil integración y adaptabilidad.

https://lh3.googleusercontent.com/-uNeSetUJQCw/W_bB07VcEpI/AAAAAAAAAEs/jKHiXjdH2O8-RhH_OjHZsmZDHU6xPa0GACL0BGAYYCw/h543/Imagen1.jpg

Fig.  2. Principios S.O.L.I.D

En la literatura y en toda la web podremos encontrar a detalle, la especificación de cada uno de estos principios, pero a diferencia de lo que hay en los libros, daremos un concepto más fácil de entender de cada uno de ellos.  Además, dejaremos para nuevas entradas del blog, la especificación mediante ejemplos aplicados. Por tanto, para dar continuidad a dicho tema, seguiremos hablando de manera general de los principios ya mencionados en base a nuestra experiencia y conocimiento.

Single responsibility principle o Principio de única responsabilidad

Nuestro primer y más “sencillo” principio, se basa en el concepto de encapsular la información o los datos, y permitir que una clase deba resolver un solo problema, y a diferencia de los que muchos inicialmente creían, es mejor una función o método tenga una sola tarea y no que resuelva los problemas del mundo. Pues con ello aseguramos que no se va a comportar de maneras inadecuadas y por el contrario su lectura será más fácil. ¡Tu yo del futuro te lo agradecerá, tenlo por seguro!

Open/closed principle o Principio de abierto/cerrado

Continuando con un poco más de complejidad, algo que será inicialmente difícil de entender, es grabar en nuestra mente este principio que dice:

Las clases, módulos y/o funciones de software deben estar abiertas para su extensión, pero cerradas para su modificación.

Pero tú te estarás preguntando ¿qué quieren decir exactamente? Y ¿por qué o qué? Entre otras preguntas, y diciendo cosas como:

– en un inicio nos decían que debíamos ver las ventajas de la sobreescritura en cualquier lenguaje orientado a objetos

Y te seguirás preguntando cosas como:

– ¿por qué lo que antes veíamos como una ventaja ahora se nos vuelve una barrera?

Pues bueno, para entender el concepto es necesario verlo aplicado, pero por el momento podemos decir que: debes adoptar capacidades de extender o heredar el comportamiento de nuestras clases sin la necesidad de modificar el código ya implementado, ya que esto nos permitirá seguir agregando funcionalidades a la aplicación, con la seguridad de que no afectará nuestro anterior código. Nuevas funcionalidades implicarán añadir nuevas clases y métodos, pero en general no deberías modificar lo que ya ha sido escrito a menos que sea necesario y que de ello dependa la supervivencia de la raza humana.

Liskov substitution principle o Principio de sustitución del Liskov

Es mi principio favorito de los 5 existentes de SOLID, para ello entendamos que el concepto de extensión o de herencia juegan un papel muy importante, sin embargo, es aquí donde lo verás más utilizado, pues Barbara Liskov en el año de 1987, en la conferencia de Jerarquía y Abstracción de datos habla sobre la importancia de la herencia entre clases padres y clases hijas, y parafraseando y ajustando un poco a nuestro entender dice que:

Si en nuestro código tenemos una clase y esta clase es heredada, es decir, tenemos una clase padre y es heredada por una clase hija, entonces podemos utilizar cualquiera de las clases hijas, y nuestra aplicación tendrá que ser siendo válida.

Reduciendo aún más este concepto podríamos ligeramente decir:

Si tienes un objeto x_1 que herede de X y otro objeto y_1 que herede de Y, pero ambos comparten el mismo padre, es decir que X e Y heredan de Z, en el momento en que cambies la referencia de x_1 hacía Y, este no debería verse afectado. Con “pseudo-pseudo código” te será más fácil de entender:

X hereda de Z

Y también hereda de Z

x_1 es un objeto que referencia a X

y_1 es un objeto que referencia a Y

Entonces puedes cambiar x_1 referenciando hacia Y

De esta manera si al realizar este cambio sucede un error, eso quiere decir que se está violando dicho principio, y por efecto deberías replantear tu código. Así que ten cuidado y te recomiendo que para ello hagas un árbol de herencia.

Interface segregation principle o Principio de segregación de interfaces

Antes de entrar en materia con este principio, debes tener muy en claro cuál es la importancia de trabajar con interfaces, estos llamados contratos o firmas. Pues vagamente te diré que nos permite desacoplar módulos y por tanto estaríamos cumpliendo cuando nos dicen en la ingeniería del software debemos realizar programas con bajo acoplamiento. Y aunque suele confundirse con el primer principio de responsabilidad única, son diferentes los principios, ya que para este principio debemos entender que no se deben crear interfaces con funcionalidades que no vayamos a utilizar y que luego se devuelvan en nuestra contra.

Te lo explicamos mejor, supongamos que tienes una interfaz A y esta tiene un pequeño contrato, método o función llamado metodoQueHaceAlgo1() y metodoQueHaceAlgo2(). Como sabrás en una interfaz sólo se indica el nombre, y su implementación se realizaría en quien implementa dicha interfaz.

Por tanto, las clases de X, Y e Z que implementen la interfaz A, tendrían que crear código para estas dos funciones o métodos, así tú no las necesites. Para ello deberías ser más específico o detallar una interfaz, y que tus interfaces sean los más concretas posible para que en su implementación en las diferentes clases, no se vean forzadas a tener métodos vacíos o innecesarios o ¡peor aún, repetidos! Ahora sí ya lo has visto en algún código, quizás es porque estás violando dicho principio.

Dependency inversion principle o Principio de inversión de dependencia

Una vez tengas claro los cuatro principios anteriores, será más fácil entender el último, ya que lo verás utilizado a lo largo de tu profesión. Estará aplicado en cada uno de los framework, que utilices y en tu propio código muy seguramente, una vez generes esa cultura de orden. Para entenderlo, sólo debes pensar que a ti no te importa cómo se implementa algo, sino que este framework se ajusta a lo que tu quieras hacer con él.

Te lo explico mejor con un ejemplo: tú necesitas conectarte a un servidor de base de datos, para ello no es necesario que conozcas su implementación de cómo se conecta, de cómo accede a los datos y demás, lo único que necesitas es una interface que permita realizar dicha conexión, pues das por hecho de lo que se implementa, está claro y funciona. Por tanto, las clases que están en un nivel superior, no dependen de las que están a nivel inferior.  ¡Siempre Piensa en abstracciones y luego sí piensa en concreto! Ya que:

Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.

La Inyección de Dependencias es uno de los métodos más utilizados que siguen este principio. Además de ello realizamos el ocultamiento de la información y encapsulación, principios importantes de una buena arquitectura    . De esta manera lograremos el modularidad en nuestras aplicaciones con calidad y efectividad. Quizás en un principio sea difícil entender este enredo, pero el tiempo y la madurez, te ayuden a entenderlos poco a poco.

Para finalizar, recuerda que la calidad hace parte importante de tus aplicaciones y para ello debes utilizar todas las herramientas posibles para lograrlo y sus buenas prácticas, además que si lo haces será más fácil lograr la mantenibilidad y escalabilidad, ya que al estar desacoplado aseguras que la modularidad se encuentre en tus proyectos y eso bastante. Por tanto, los cinco principios SOLID, son parte fundamental del conocimiento de ingeniería del software y debes tenerlo en cuenta en todo lugar. Así que prepárate para ser el mejor y lograrás excelentes aplicaciones perdurables en el tiempo.

¿Deseas conocer las alternativas de desarrollo de software que tenemos para transformar digitalmente tu empresa o emprendimiento?

Nuestro equipo Sunset Software House está listo para ser tu aliado tecnológico en este proceso.


¡Déjanos un mensaje y atenderemos pronto tu solicitud!
mercadeoyventas@sunsetswh.com