[S.O.L.I.D.] Single responsibility principle / Principio de Responsabilidad Única

2
10900

Single responsibility principle / Principio de Responsabilidad Única

0. Índice de contenidos.

1. Introducción

Este es el primero de una serie de 5 tutoriales explicando los principios S.O.L.I.D (Single responsibility, Open-closed, Liskov substitution, Interface segregation y Dependency inversion).

Estos principios, aunque eran conocidos anteriormente por separado, fueron popularizados en este acrónimo por Robert C. Martin.

Su aplicación ayuda a que el código tenga una alta cohesión y un bajo acoplamiento.

Cohesión: Un módulo tiene un alto grado de cohesión si mantiene “unidas” cosas que están relacionadas entre ellas y mantiene fuera el resto.

Acoplamiento: Acoplamiento es la medida de la fortaleza de la asociación establecida por una conexión entre módulos dentro de una estructura software.

Mucha gente no tiene claro estos conceptos, por lo que para dar una definición breve podríamos decir que tener alta cohesión y bajo acoplamiento ayudan a que el el código que expresa una funcionalidad concreta esté bien unido, pero separado de otras partes ajenas al mismo.

Esto ayuda a la reutilización y a hacer el código menos frágil, con esto conseguimos que al hacer una modificación en una parte del programa, esta no afecte en cascada a muchas otras partes (fragilidad del código).

Los principios están un nivel de abstracción por encima de los patrones de diseño y están también por encima del lenguaje que estemos utilizando, son conceptos a tener en cuenta mientras programamos.

2. Single Responsibility Principle / Principio de Responsabilidad Única

La primera letra de SOLID hace referencia al principio de Responsabilidad Única. La idea de este principio es fácil de entender, pero conforme un programa se va haciendo más grande, es más difícil de implementar.

Lo que nos pide este principio es que cada clase debe tener una unica responsabilidad, por lo que si estamos programando una clase que se ocupa de diferentes cosas es conveniente partirla en 2 o más clases.
Con esto se consigue mayor mantenibilidad y se clarifica el código, haciéndolo más mantenible.
Muchas veces estamos tentados de programar demasiadas cosas en una misma clase, pero esto aumenta el acoplamiento de dos funcionalidades que pueden cambiar por razones diferentes o en momentos distintos.

3. Ejemplo

A mi, para entender un concepto nuevo me gusta apoyarme en ejemplos concretos.
Vamos a ver uno muy simple.

Tenemos que diseñar un supermercado, una primera aproximación podría ser:

Tenemos una clase empleado que puede cobrar a los clientes en la caja registradora, pero también repone el Stock.

A priori no parece mala idea.
Pero supongamos que nos piden que cambie el proceso de cobro a clientes añadiendo funcionalidades de pago con tarjeta por ejemplo. O que el supermercado crezca y ahora se contrate gente específicamente para reponer el stock de productos.
En ambos casos tenemos que tocar en la clase empleado, y es posible que una modificación en una funcionalidad pueda tener efectos colaterales en la otra.

Si seguimos este principio deberíamos haber hecho un modelo similar a este.

Así las peticiones de cambio serán más sencillas de implementar y una nueva incorporación al equipo de desarrollo no tendrá tantos problemas para entender el código.

Hay que recordar que en orientación a objetos, los objetos no tienen necesariamente que corresponderse con objetos del mundo real, y que aunque en realidad exista una sola persona que se ocupe de ambas cosas, podemos crear un objeto para cada rol que desempeña.

4. Principio S.O.L.I.D.

2 Comentarios

  1. Hola Samuel Martín, muchas gracias por el tutorial lo estoy leyendo y de seguro me aclarará algunas cosas de Solid.
    Pero tengo una pregunta, por ejemplo en una capa de Datos tengo la clase “Empleado” y dentro de ella los siguientes métodos:
    – Insertar
    – Actualizar
    – Borrar
    – Consultar
    La duda es si se está violando el principio de responsabilidad única por tener varias responsabilidades, es decir varios métodos o tareas (insertar, actualizar…) si es así ¿Cómo sería el esquema?
    Un saludo!

Dejar respuesta

Please enter your comment!
Please enter your name here