Principios SOLID

Los principios SOLID de programación, también conocidos como SOLID principles o principios SOLID para programación orientada a objetos (SOLID OOP), son una serie de cinco reglas o principios de la programación orientada a objetos recopiladas por Robert C. Martin (uncle Bob) en su libro «Agile Software Development: Principles, Patterns and Practices».

El principal objetivo que consigues aplicando los principios SOLID es que tu software sea más limpio, flexible, escalable y mantenible. O resumido en un sólo adjetivo: código de mejor calidad.

Siguiendo los principios SOLID, también harás que tu código tenga una alta cohesión y bajo acoplamiento.

Cohesión y Acoplamiento

El acoplamiento y la cohesión en programación son dos conceptos muy importantes que tienes que tener en cuenta cuando desarrollas software.

A continuación, te ayudo a entender qué es la cohesión y el acoplamiento mediante ejemplos.

Cohesión

Una pieza de software tiene una alta cohesión cuando tiene un único propósito, y todas sus clases, métodos y propiedades definen una funcionalidad única, relacionada con una sola cosa. Dicho de otro modo, la funcionalidad desarrollada está localizada en un único módulo.

Por «pieza de software» puedes entender desde un framework o librería, hasta un servicio más pequeño, incluso un objeto creado mediante una única clase o estructura.

La cohesión en programación está estrechamente relacionada con el primer principio SOLID: el principio de responsabilidad única.

Un ejemplo sobre alta cohesión podría ser tener un servicio que gestione toda la lógica de persistencia de tu aplicación y que no haya ningún objeto que se encargue de persistirse a sí mismo.

Acoplamiento

El acoplamiento en programación orientada a objetos se refiere al grado de independencia que tienen dos piezas de software entre sí.

Dados dos objetos, A y B:

• Si A depende de B para realizar su tarea, entonces se dice que A está acoplado a B.
  • ¡Ojo!, aunque A esté acoplado a B no quiere decir que B lo tenga que estar con A. En resumen, el acoplamiento en programación es unidireccional, no bidireccional.
• Si A no depende de B y B no depende de A, entonces se dicen que A y B están desacoplados.

Por ejemplo, cuando en iOS aplicamos la navegación de un ViewController hacia otro en el propio controlador, estamos acoplando el ViewController que efectúa la navegación al ViewController de destino.

Concretando un poco más, tenemos la típica pareja List-Detail: PostListViewController y PostDetailViewController. Si aplicamos la navegación dentro del PostListViewController hacia el PostDetailViewController:

• PostListViewController «conoce» a PostDetailViewController, sabe que tiene que navegar hacia él. En este caso, la lista está acoplada al detalle.
• Sin embargo, PostDetailViewController no tiene por qué conocer que lo ha presentado un PostListViewController, así que no estaría acoplado a la lista.

Si cuando queremos realizar cambios en un objeto tenemos que cambiar otro, es que existe acoplamiento entre ellos. Por ejemplo, si queremos cambiar el método init del PostDetailViewController, también tendríamos que cambiar el código en PostListViewController para reflejar ese cambio. En este ejemplo se demuestra que la lista está acoplada al detalle.

Idealmente, los UIViewController sólo deberían encargarse de controlar la vista, no de la navegación. Veremos esto con más detalle en la explicación de los principio SOLID.

Diseñar software con bajo acoplamiento ayuda a facilitar la reutilización de los objetos, así como su testabilidad y mantenibilidad.

¿Qué es SOLID en programación?

SOLID son las siglas o el acrónimo de los 5 principios o reglas que hay que seguir para construir software de calidad.

• S – Single Responsibility Principle: principio de responsabilidad única, también conocido como SRP.
• <strong>O</strong> – Open/Closed Principle: principio abierto/cerrado.
• <strong>L</strong> – Liskov Substitution Principle: principio de substitución de Liskov
• <strong>I</strong> – Interface Segregation Principle: principio de segregación de interfaces
• <strong>D</strong> – Dependency Inversion Principle: principio de inversión de dependencias

Ahora paso a explicarte cuáles son los principios SOLID utilizando ejemplos que faciliten su comprensión. Y cómo no, ¡en Swift!

1. Principio de Responsabilidad única

Es el Single Responsibility Principle, también conocido por sus propias siglas en inglés «SRP».

«Un objeto debería tener una, y sólo una única razón para cambiar»

Viene a decir que un objeto (o pieza de software más grande) debería ser responsable solamente de una cosa, de una única tarea. Y si éste tiene que cambiar, sólo debe hacerse por una única razón.

He escrito un artículo explicando exclusivamente el Principio de Responsabilidad única, con ejemplos explicados y en un contexto de desarrollo iOS.

Pincha aquí debajo 👇👇👇

2. Principio Abierto-Cerrado

El Principio Abierto/Cerrado, también conocido como Open/Closed Principle o por sus siglas OCP, es el segundo de los 5 principios SOLID.

En su definición, este principio dice que «un módulo de software debería estar abierto a extensión pero cerrado a modificación».

No sé tú, pero yo con esta definición no me enteré de nada la primera vez que la leí, así que te la voy a intentar explicar de manera sencilla y, como siempre, con ejemplos.

Abre el siguiente artículo donde te explico en detalle todo sobre este principio SOLID Open/Closed.

Pincha aquí debajo 👇👇👇

3. Principio de Sustitución de Liskov

El Principio de sustitución de Liskov, también conocido como Principio Liskov, Liskov’s Substitution Principle o LSP, es el tercero de los Principios SOLID.

Este principio nos explica cómo se debería utilizar correctamente la herencia y el polimorfismo. Ambos son muy poderosos si los aplicas correctamente, pero también pueden ser contraproducentes y afectar a la escalabilidad y mantenimiento de tu software si los usas simplemente como un mecanismo para modelar al 100% la realidad o reutilizar código.

He escrito un artículo que habla en detalle sobre el Principio de Sustitución de Liskov.

Pincha aquí debajo 👇👇👇

4. Principio de Segregación de Interfaces

El Principio de Segregación de Interfaces, también conocido como Principio de Separación de Interfaces, Interface Segregation Principle o ISP, es el cuarto de los principios SOLID de la programación orientada a objetos. Éste reza:

«Los objetos no deberían verse forzados a depender de interfaces que no utilizan»

Esto viene a decir que cuando creamos interfaces (protocolos) para definir comportamientos, los objetos que se conforman a ellos no deberían verse forzados a implementar métodos que no va a utilizar.

Pero ojo, porque la definición original no se refiere a los objetos que se conforman a la interfaz en sí, si no a aquellos que utilizan la interfaz. Lee el artículo hasta el final, ya que te lo explicaré con un par de ejemplos para que entiendas la diferencia a la perfección.

5. Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias, también conocido como Dependency Inversion Principle o DIP, es el último de los Principios SOLID de la programación orientada a objetos.

La definición original que dio Uncle Bob dice:

1. Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones.
2. Las abstracciones no deberían depender de los detalles. Los detalles deben depender de abstracciones.

A simple vista, no queda claro a lo que se refiere, así que en el artículo siguiente explico en profundidad este principio.

Además, también te cuento si es lo mismo la «Inversión de Dependencias» que la «Inyección de Dependencias». ¿Lo sabes?

👇👇👇

Comparte este artículo

Si te ha gustado la serie, dale mucho amor a este artículo compartiéndolo en tus redes sociales.

👇👇👇