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.
PRINCIPIOS DE LA PROGRAMACIÓN SOLID: Un conjunto de buenas prácticas que nos ayudan a crear código orientado a objetos más mantenible, reusable y sostenible a largo plazo. • Principios de programa...
#solid #java #dotnet #programacion #tutorial #desarrollosoftware
#objectorientedprogramming #programming #softwaredevelopment
🔔 ¡Suscríbete ya! kzbin.info?sub_confi...
➕ Más tutoriales en: www.makigas.es
⭐ Programa de miembros: youtube.com/@makigas/join
📝 Foros de la comunidad: foro.makigas.es
💬 Servidor de Discord: discord.makigas.es

[@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❤

[@daniellopezlozano8683]

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!

[@gindCode]

Gracias

[@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! 🤜🏽🤛🏽

[@aresnev9382]

Dónde se habla poco? Levantas una piedra y tenés 1800 videos de patrones de diseño. Igual makigas es otro nivel

[@ddutra]

@@aresnev9382 El canal siempre tiene beneficios en el algoritmo qdo hay mas comentarios! Entonces, en el Brazil, el Google ADS, dice q la expression 'patrones de diseño' tiene d 10 a 100 pesquisas mensuales, PHP y SOLID, d 10mil a 100mil. Pero, Java tiene d 100mil a 1millon! O sea, s habla poco sobre 'patrones de diseño'! 🤷🏽‍♂🤷🏽‍♂ No lo digo yo, lo dice el Google, y s el Google lo dice, entonces, es verdade! 😂😂

[@rayito845]

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

[@vanityzzz]

Muy buena explicación, gracias.

[@jetmarte1975]

Oro puro, gracias Dani

[@davzuzu]

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

[@videovideo166]

perfecto!!! gracias maki!!!!

[@rodolfosilvera47]

Muy buen video

[@florentinobajo]

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

[@Forrest-777]

Buen video

[@Vicho1079]

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?

[@makigas]

Lo normal cuando me encuentro CRUDs es que la responsabilidad sea del CRUD completo, o sea que habría una clase completa para todo el CRUD con métodos para insertar, sacar, listar, actualizar y borrar. Lo que sí suele verse en aplicaciones de este estilo es un desacoplamiento entre el DAO que accede a base de datos y quien lo vaya a consumir. Por ejemplo todas esas aplicaciones Spring o .NET donde se separan el Repository como un servicio aparte del Controller, que es una clase separada.

[@ciltocruz]

​@@makigas Entonces sería algo así? Controlador -> CrudService (4 operaciones) -> cada una de las operaciones invoca a un caso de uso concreto (ergo, 4 clases que son: CreateUseCase, ReadUserCase, UpdateUserCase, DeleteUserCase) y cada uno de estos casos de uso, con el mismo repository ¿Es así lo que comentas?

[@ciltocruz]

Leyéndolo otra vez creo que querías decir que el controlador agrupa todas las opciones del CRUD pero que hay una clase que gestiona cada operación por separado. ¿Así?

[@CRISTIANDAMIANCANTERO]

Se viene unos cursitos de quarkus?

[@makigas]

Están viniendo, vigila el feed de suscripciones o te los pierdes cuando salgan 💪

[@soybelena]

Esto no es polimorfismo? 😮