SOLID: Principio de Responsabilidad Única (SRP)

El principio de responsabilidad única o Single Responsability Principle (también conocido como SRP) es uno de los cinco principios SOLID que ayuda a modelar código orientado a objetos de una manera más robusta y mantenible a la larga. El principio SRP nos dice que una clase sólo debe tener una única responsabilidad y por lo tanto una única razón para cambiar en el futuro. Es uno de los más fáciles de comprender pero en este vídeo proporciono un ejemplo que permita comprender cómo modelar un sistema orientado a objetos respetando este principio.

#solid #java #dotnet #programacion #tutorial #desarrollosoftware
#objectorientedprogramming #programming #softwaredevelopment

[lacuevadelcodigo]

Muy buen video!! Solo dos puntos que me gustaría comentar al respecto:

1 - Cuando hablamos de este principio siempre decimos que una clase solo tiene una responsabilidad. Quizás esté implícito pero me parece bien recordar que también se hace referencia a que una responsabilidad solo debería estar en un único sitio. Es decir, no pensar solo en que esa clase tiene una responsabilidad sino que esa responsabilidad solo este en un sitio para no tener la misma lógica en sitios diferentes (aunque esos sitios solo tengan una responsabilidad)

2 - También hay que tener mucho cuidado con la idea de que el principio de responsabilidad unica nos "dice" que no tenemos que repetir el código (ya que esa responsabilidad debería ir encapsulada en un único sitio). Ojo, es posible que a día de hoy parezca una duplicidad pero que por las reglas de negocio esas duplicidades puedan evolucionar por caminos diferentes, siguiendo el ejemplo que comentas imaginemos que en dos sitios está el mismo formulario para contextos diferentes de nuestra aplicación, es posible que a día de hoy se utilicen los mismos campos y la lógica de validación sea la misma, pero puede ser que por el contexto donde se utilicen luego puedan añadirse más campos en uno y no en otro o que la lógica de esa validación cambie en un contexto y en otro no.

Conclusión: Como con todo no hay que volverse loco y pensar que tenemos que ser super puristas con estos principios, son muy buenos para mejorar técnicamente pero tenemos que ser los programadores quien con criterio los utilice correctamente❤

[daniellopezlozano]

Nunca pararé de comentarlo. Esto es un gran trabajo enhorabuena makigas a la espera de los otros dos principios.

[leofabioFAC]

Excelente explicacion!, en lo personal me ayudo mucho comprender claramente el concepto de cohesion para entender el SRP!, salu2!

[ddutra]

Poco s habla sobre el uso d patrones en el desarrollo de softwares, pero, los patrones son tan revolucionarios como lo son las classes! Traer este tema al canal es otra gran contribuicion, Dani! 🤜🏽🤛🏽

[rayito]

SHIIII POR FIN MAS SOBRE ESTE TIPO DE CONTENIDO GRACIAS!!!

[davzuzu]

Hola, gracias por el aporte. En la miniatura dice Simple en lugar de Single.

[Vicho]

algo relacionado con esto me paso ayer. ¿porque chucha la clase String no tiene la responsabilidad de tener una función reverse() y la clase StringBuilder si?
¿Eso seria un caso de abuso de este principio?

[ciltocruz]

Hola, Dani. ¿Esto significa que el típico CRUD debería disgregarse en 4 clases? ¿No haría eso que, por ejemplo, un controlador, tenga demasiadas dependencias, una por cada operación a realizar?

[florentinobajo]

Me encanta como explicas la lógica de la división de clases. +1