De por qué en los principios SOLID no conocemos a Bárbara

Creo que tenemos que empezar claramente por el principio (obvio) antes de poder hablar de quién es Bárbara.

¿Qué son los principios SOLID?

Para quien no esté al día en el mundo del desarrollo, SOLID son unos principios que sirven para hacer el código más mantenible y extensible, así como un diseño con una base más limpia. Como todas estas cosas, nos valen de guía sin ser una medida altamente estricta ya que sirve de referencia, dado que cada software que desarrollemos es un mundo y está determinado por varias cosas entre ellas la lógica de negocio y ,como consecuencia, su conceptualización integral.

SOLID

Como es conocido en el mundo informático es un acrónimo nemónico que indica lo siguiente:

La S corresponde al principio de Responsabilidad Única en la cual una clase tiene que tener una sola responsabilidad. Esto también se aplica a las funciones. La idea es, sobre todo, para que no perdamos el control sobre el código. Además si tenemos una clase que haga muchas cosas, si hubiera que cambiarlo se corre el riesgo de cambiar cosas que no tenías intención.

La O corresponde al principio de Abierto/Cerrado (Open/Close) .

Significa en términos generales que tu código tiene que estar abierto a extensión pero sin necesidad de modificarlo. Por ejemplo,supongamos que creamos un módulo de de recibos y tenemos los métodos de pago incluidos dentro. Si queremos añadir una nueva implementaciónd de un nuevo método de pago tendríamos que tocar el módulo de recibos entero. Si sacásemos los métodos de pago a una interface, con crear una clase aparte que la implemente sería suficiente.

La L es el principio de Sustitución de Liskov y aquí es donde entra Bárbara en juego. Lo retomaremos más adelante.

La I es el principio de Segregación de Interfaces

Viene a ser que se utilicen las Interfaces de manera coherente, creándolas más concretas para no generar métodos «huérfanos» todo ello con el equilibrio pertinente de no hacer sobreingeniería (pensemos en quien le toque depurar una clase que implementa varias interfaces).

La D corresponde al principio de Inversión de Dependencias, que significa que las clases de alto nivel no deberían de depender directamente de las de bajo nivel,sino depender de las abstracciones de las mismas. El típico ejemplo es si tenemos una herramienta de gestión de datos (alto nivel) que pasan por una conexión a una base de datos(bajo nivel) MySQL, si en un futuro quisiéramos cambiar el sistema de base de datos tendríamos que cambiar toda esas dependencias. Para ello podriamos crear una interfaz de alto nivel que fuera La base de datos (Database) que sería la abstracción y el bajo nivel sería MySQL, MongoDB, postgreSQL… o lo que querríamos cambiar en un futuro.

 

El principio de Sustitución de Bárbara Liskov

Bárbara Liskov, trabaja en el MIT. Es graduada en matemáticas y pionera en la Programación Orientada a Objetos. Ha sido Doctora Honoris Causa y ha recibido méritos por su trabajo en su campo. Dirigió varios proyectos de lenguajes de programación y junto a otra teórica informática (Jeannette Wing) sentó la base para su principio de Sustitución. Si, el de Bárbara Liskov.

Este principio se basa en que si usamos una clase padre y la extendemos a clases hijas, tiene que ser posible utilizar cualquier clase hija, esto nos hace que cuando extendemos una clase no alteremos el comportamiento de la clase padre, pero sí que permanezca compatible. Este concepto es básico para desarrollar librerías.

Vamos a poner un ejemplo.

Pensemos que tenemos una clase padre Documento(Document) con su definición de métodos abrir open() y escribir write(). Ahora tenemos una subclase que es un documento de solo lectura (ReadOnlyDocument) y por tanto al extender de la clase padre hereda el método write(). Pero aquí dicho método no tiene sentido dado que es un documento de sólo lectura por lo tanto tendremos que lanzar una excepción. Ahí ya nos tiene que oler que será necesario crear quizás una subclase para los documentos que si puedan escribir en el cual podrá tener un método para escribir y en la clase padre simplemente sobrescriba el método open() para que el ReadOnlyDocument tenga el método padre que le corresponde y use.

Otras soluciones en estos casos pueden ser que crear una interface y al implementarla en cada una de los métodos, que haga el contenido que deba hacer en su contexto. En definitiva, saber utilizar la herencia y contextualizarlo al caso. Creando la abstracción de manera cohesionada, esa es la idea.

 

Hemos hecho este post dándole voz a Bárbara, a una de muchas que se siguen nombrando solamente por su apellido generalmente. No, no tenemos problema en que se nombre así pero creemos que nos perdemos parte de la historia porque presuponemos que Liskov es un tiarrón, un man y luego pensamos que quien se sale de ser un man no es probable que pueda tener la misma importancia que cualquier otra persona porque no tenemos referentes pero sí. Si los tenemos. Tenemos que hacer labores de investigar y des-invisibilizar.

Ya, de aquí a un tiempo ya se hace pero es necesario ser cansinas, de verdad. Ojalá no fuera necesario hacerlo pero si que lo es. Queremos dejar huella para que en esta fase que estamos, recordarnos constantemente que si que se puede, y no solo eso sino es que se debe, debemos tener diversidad en la Tecnología.

 

** Para este artículo quizás primero tengas que tener conocimientos en la Programación Orientada a Objetos. Saber previamente qué es una clase, métodos, atributos,herencia e interfaces. También tener una visión para entender el ciclo de vida de un software. Si no tienes esos conocimientos los puedes buscar o no tenerlos y empaparte de lo que no sabes,sin presiones, ya saben… a fuego lento.