Solid

Toda persona que se dedique a la programación debe tener en cuenta unas bases de desarrollo que, incluidas en el software ya generado, tienen que cumplir dos partes que, en base a mi experiencia personal, deben ser lo más importante:

1. El código debe ser fácilmente escalable.
2. Los errores informados deben identificarse rápidamente y solucionarse en el menor tiempo posible.

Por poner un ejemplo donde esto pueda verse más claro, cuando tenemos una incidencia al guardar un registro debemos conocer dónde se está produciendo el error. O si por ejemplo, en otro caso tenemos una nueva funcionalidad, esta debe tener el menor impacto posible en la aplicación original. Si nuestro trabajo cumple con estos requisitos, el impacto en lo que ya existe apenas será notable.

Teniendo en cuenta esto, existen 5 principios, que no reglas cerradas, en los que basarse a la hora de crear software:

1. Single Responsability Principle

La descripción más famosa del Principio de Responsabilidad Única es la de su propio autor Robert C. Martin, que aboga porque «una clase debe tener una y solo una única razón para cambiar» y resume la importancia de no repetir código y mantener de forma constante la calidad del mismo.

2. Open Close Principle

A nivel teórico el Principio de Abierto/Cerrado establece que «una unidad de software debe quedarse abierta para su extensión, pero cerrada para su modificación», pero hablando de forma más genérica este principio hace deferencia a que la función, módulo o clase se debe poder extender sin necesidad de cambiar su código fuente.

Esta expresión fue utilizada por Bertrand Meyer sobre la construcción de software orientado a objetos a finales de la década de los 80, pero hubo una «redefinición» polimórfica del principio durante los 90 en relación al uso de herencia mediante clases abstractas.

Robert C. Martin siguió este enfoque, que hasta el día de hoy, es el más popularizado.

3. Liksov Substitution Principle

«Cuando una clase hereda de otra, la clase hija debe poder sustituir al padre sin que haya un mal funcionamiento» es la traducción más cercana al principio exacto, que desde mi punto de vista es el más útil pero también el más complicado de seguir.

Para que este principio se cumpla, se requiere que tanto las herencias como las interfaces asociadas estén bien configuradas.

4. Interface Segregation Principle

Basado en el desacoplamiento de interfaces, el Principio de segregación de interfaces indica que «los clientes de un programa solo deberían conocer de éste aquellos métodos que realmente usa, y no aquellos que no necesitan utilizar».

5. Dependency Inversion Principle

La generación de software tradicional se ha ido estableciendo en base a módulos de alto nivel que dependen de los módulos de bajo, y este principio es el que ha conseguido dar un giro de paradigma con respecto a las dependencias.

El Principio de Inversión de Dependencias establece que:

• Los módulos de alto nivel no deben depender de los módulos de bajo nivel, sino que ambos deben depender de abstracciones, donde lo más común son las interfaces.
• Las abstracciones no deberían depender de los detalles, sino los detalles de las abstracciones.

Cuando hablamos de alto nivel nos referimos a los módulos que están más cerca del usuario, y cuando hablamos de bajo nivel son los módulos que están más cerca del núcleo de nuestra aplicación.

Y con respecto al segundo punto pongamos un ejemplo: si al hacer la compra en un supermercado en el momento de realizar el pago llamamos al método PagarEfectivo(), el hecho de que sea efectivo es un detalle, y la forma de pago no debería estar ligada al detalle de que se realice con tarjeta o efectivo. Por eso, lo ideal sería nombrar al método como Pagar() de forma que a la implementación no le interese qué opción de pago utiliza el cliente.

Si nos remitimos a la introducción del artículo cabe recordar que los principios SOLID son eso, principios y no reglas cerradas para desarrollar software. Aun así, aplicando estos principios a nuestro código, el mantenimiento, la extensión y la compresión del código se simplifican cuando las aplicaciones son muy extensas.

Por eso, tod@ desarrollador/a cuyo trabajo esté orientado a objetos deberían seguir estos principios a la hora de crear sistemas fáciles de mantener y escalables a través del tiempo.

SOLID