Principio de responsabilidad única

Compartir esta publicación

Share on facebook
Share on linkedin
Share on twitter
Share on email

En la programación orientada a objetos existen cinco principios básicos (SOLID) que, bien aplicados, marcan la diferencia entre un buen y un mal diseño. La diferencia entre una aplicación fácil de mantener y una que no. La diferencia entre un buen desarrollador y uno que no lo es. En este articulo vamos a hablar más sobre el principio de responsabilidad unica. 

 

  • Single Responsability Principle (Principio de responsabilidad unica )
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

 

Vamos a empezar por el primero de todos, el principio de responsabilidad única, definido por Robert C. Martin en su libro Agile Software Development, Principles, Patterns, and Practices. Es un concepto muy simple de explicar, sin embargo, difícil de poner en práctica. Como su propio nombre indica, este principio habla de que una clase o módulo debe tener una única responsabilidad.

Dentro del contexto del SRP, la responsabilidad es definida como una razón para cambiar. Por tanto la frase de Robert C. Martin es una definición perfecta sobre qué es el principio de responsabilidad unica:

 

“A class should have only one reason to change”.

 

Cumpliendo este principio te aseguras que tu clase o módulo tiene una cohesión alta, lo que significa que tu clase no hace más de lo que debería hacer. En definitiva, una única razón para cambiar. Si, por lo contrario, construyes una clase con más de una responsabilidad, lo que estás haciendo es acoplar dichas responsabilidades, y esto conduce a un diseño frágil y difícil de mantener, con todo lo que ello conlleva.

 

Ejemplo

single responsibility principle

 

En este simple ejemplo se puede ver una clase Rectángulo que tiene dos métodos: Area() que tiene la responsabilidad de devolver el área del rectángulo y otro método,
draw(), que tiene la responsabilidad de dibujar el rectángulo en sí.

En este diseño se puede apreciar que, si por cambios en la GUI, debemos modificar la clase Rectángulo, entonces estamos obligados a testear, de nuevo, la otra aplicación que ataca a la misma clase. La solución a este problema es dividir dicha clase en dos diferentes, de tal manera que cada clase tiene una única responsabilidad. Una será la responsable de calcular, y otra de pintar:

 

single responsibility principleSRP

 

Hay que tener en cuenta que este principio desemboca en muchos otros matices y conceptos, ya no sólo los que entran dentro de SOLID, sino otros que se deben conocer y saber aplicar para conseguir una aplicación con un diseño sólido. 

 

Si este artículo te gustó, te puede interesar: 

 

Por qué Kotlin?

Patrón MVP en iOS

F-bound en Scala

Sobre Dioses y procrastinación

Arquitectura de microservicios

Fibers en Nodejs

Simular respuestas del servidor con Nodejs

 

Suscríbete a nuestro newsletter para estar al día de los eventos, meetups y demás artículos!

Conversion Post ES

Una respuesta a “Principio de responsabilidad única”

  1. RENE SANTIAGO RESENDIZ dice:

    Amigo, creo que están invertidas tus imágenes, buen artículo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Suscríbete a nuestro boletín de noticias

Recibe actualizaciones de los últimos descubrimientos tecnológicos

Acerca de Apiumhub

Apiumhub reúne a una comunidad de desarrolladores y arquitectos de software para ayudarte a transformar tu idea en un producto potente y escalable. Nuestro Tech Hub se especializa en Arquitectura de Software, Desarrollo Web & Desarrollo de Aplicaciones Móviles. Aquí compartimos con usted consejos de la industria & mejores prácticas, basadas en nuestra experiencia.

Posts populares
PDF gratuito Software Interview Series

¿Tienes un proyecto desafiante?

Podemos trabajar juntos