Por qué no se entiende la S de SOLID: Principio de Responsabilidad Única
Вставка
- Опубліковано 28 кві 2021
- La S de los principios SOLID es el principio más conocido, pero uno de los más complicados de entender. ¡Hoy os contamos cómo sacarle todo el jugo!
🚥 ¡Haz nuestro curso de refactoring! 👉 bit.ly/curso-refactor
🔗 Enlaces mencionados
├ Vídeo de la S de SOLID de Codely del 2015 • SOLID - Principio de R...
├ Post Uncle Bob sobre SRP blog.cleancoder.com/uncle-bob...
├ Paper de Uncle Bob sobre SRP www.cs.utexas.edu/users/downi...)
└ Paper de Dijkstra sobre Separation of Concerns www.cs.utexas.edu/users/EWD/e...
{▸} Codely
├ 🎥 Suscríbete: ua-cam.com/users/CodelyTV?sub_co...
├ 🐦 Twitter Codely: / codelytv
├ 💂🏼 Twitter Rafa: / rafaoe
├ 🧔🏻 Twitter Javi: / javiercane
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🟦 Facebook: / codelytv
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Наука та технологія
¿Qué letra de SOLID consideras la más difícil? 🤔
la S xD
L
La letra más difícil de solid es la que no está escrita y que dice que no hay que ser talisolids.. Que es mucho más razonable tener una filosofía solid y saber cuándo aplicarlo que aplicarlo sin entenderlo y que todo sea un spaguettie-code con sobreingeniería :D
Mi opinión es que la L (P sustitución de LISKOV) es la más compleja de entender de forma correcta.
D
Los papers no son simples post de los años 80 y 90, los papers son documentos academicos que pasan por varias revisiones de la institucion desde donde escribe el autor y de quien los publica....Porfavor no comparar ambas cosas, es como comparar una hamburguesa de Macdonals con un sandwich de costilla del mejor restaurant frances
Nananana encantado con este video, me volaron la cabeza! Por favor, sigan con las demas letras de SOLID!
Son muy buenos, aunque a veces les gana la pasión y hablan mucho y dicen poco, en México le decimos a esto, Cantinflear, pero creo que también tiene que ver que mucha terminología de la que hablan no es común para los principiantes, sin embargo, debo decir que me encanta la pasión que le ponen a estos temas, ya que algunos los consideran triviales, y la verdad es que no lo son, de hecho son un diferenciado entre un buen desarrollador y uno no tan bueno. Mi admiración y pues me quede esperando los enlaces a los artículos de la investigación que hicieron, ¿tendré que buscar en el video para encontrarlos, o nos ayudan a ponernos acá?.
Gracias y saludos
+1 Se nota que les encanta su trabajo pero divagan mucho.
Cómo bien dices, es porque mencionan términos con los que no estás familiarizado. También soy de México y me pareció importante cada comentario para ponerse en contexto 😁
oye soy de Nicaragua y no pense que se usara por otras personas el termino "Cantinflear"
Excelente muchachos, informativo y ameno.
Gracias 😌
Muchas gracias por todo el conocimiento que comparten!! Me gustaría que hagan un ejercicio de investigación similar a este pero con Liskov substitution principle. Más que nada para entender casos prácticos donde vale la pena aplicarlo. Saludos!!
Cuando mas os escucho mas se lo que no se, 🤣
Jajaja
jajjajaja me pasa lo mismooo
Solo se que nada se
Me ha gustado el video porque es necesario replantearse los conceptos que crees haber entendido, y sobretodo actualizarlos y adaptarlos al contexto en el que trabajes. No hay que divagar tanto, un principio que no puedes definir en una frase no es un principio, es un planteamiento que necesita pulirse. Que feo queda eso de extenderse llegando a abusar de sinónimos y genéricos para acabar cayendo en ambigüedades o incluso en contradicciones, y que al final cada uno interprete el principio a su manera.
Que gran video y buena explicación! Vale la pena que hablen sobre Liskov Substitution porque considero que es el mas confuso y hay mucha mal interpretación en artículos, incluso me ha tocado ver canales donde lo confunden con el principio de Interface Segregation
Cada tanto vuelvo a este video porque a este tipo de conceptos le vengo dando vuelta hace años y el otro día me di cuenta de algo referente a esa "Razón para cambiar". Comparado con el caso extremo del video original, en el que se planteaba un solo método público para una clase.
Tenía que implementar un registro de usuario y un login. En el registro guardo el password encriptado y en el login se hace el check con el password que se envía al login y el hash. Tengo una interfaz Crypt que tiene el método encrypt y check para no acoplarme a la librería bcrypt de node y si bien, el método encrypt lo uso en el registro y el check en el login, es decir, en casos de uso diferente, en el video original se hubiese hecho alusión a que debería tener una clase Encrypter y EncryptVerifier, pero el problema de hacer esto es que se pierde totalmente la cohesión que debería existir entre la encriptación y la verificación de la misma, porque la realidad es que deberían ir de la mano, si por algún motivo quiero remover la librería bcrytp necesito que tanto el cifrado como la verificación se hagan con la misma libería, ya que si separo en diferentes clases corro el riego de que el cifrado se haga con bcrypt y la verificación se haga con otra cosa y por ende pierdo la cohesión, tranquilamente en el caso de uso del login podría inyectar una implementación para el check y en el caso de uso del registro otra, lo cual haría que no funcione, es decir, tengo que acordarme de que uso bcrypt en dos clases si algún día tengo que cambiar de librería, al estar tanto el encrypt como el check en la misma interfaz, cuando vaya a tener que cambiar de librería, en ese mismo momento deberé actualizar ambos métodos, porque la razón para cambiar de esa implementación sería el cambio de librería.
Me parece muy interesante, ya que como bien comentan hay distintos niveles para interpretar las responsabilidades. No está mal de manera intrínseca tener un repositorio para el guardado y otro para la lectura. En muchas ocasiones los principios se llevan como complemento al corazón del negocio. Respetando el objetivo de cohesión y acoplamiento
Claro con el tiempo aprendemos, mejoramos y salen mejores versiones para aplicar en el software.
Hacedlas todas!!!!!
Creo que el SRP no es otra cosa que alta cohesión. Cuando se entienda qué es y se llegue a ella en el código, habremos cumplido con este principio.
Totalmente de acuerdo 👏👏
Es la cohesión aplicada a un Rol, me extraño que en todo el video no mencionaron nunca la palabra Rol, creo que si el principio se llamar Principio de Rol Único traería menos confusión.
@codelyTV no habéis puesto en la descripción el link al paper que comentáis en el vídeo. 👀
Añadidos en la descripción! 😊
💚😊
En el curso que tienen de SOLID ya corrigieron el error? Después de ver este vídeo me quedé con ganas de más, espero iniciar ese curso pronto 😬👌
En el curso ya se tuvo en cuenta y en ningún caso se llegó a publicar ese ejemplo. Sólo estaba en el vídeo de UA-cam que mencionamos 😊
Efectivamente es una fumada muy interesante... gran resumen jajaja
Sin duda el mas complicado es SRP, por que el nombre es muy engañoso. Muy buena explicación.
Simpre que hablaban de SRP no entenía porque aplicaban al extremo! de hecho estoy seguro que en algún momento les comenté: sobre todo cuando a las clases les ponían nombres con verbos y una solo función dentro alegando que eso es SRP.
Perdón, pero necesito decirlo: Ahora tampoco estoy entendiendo que es es lo que estan rectificando!
Clases con una sola función: A eso yo le llamaría patrón Command (Design Patterns + GoF) y lo de poner nombre a los verbos se le llama cocificar una acción, ejemplo Agregar Usuario seria CasoUsoAgregarUsuario (AddUserUseCase, AddUserController) o lo que quieras
@@kodenix perfecto! A lo que voy es que SRP no implica para nada que las cosas sean de esa forma que acabase de comentar como ejemplo. Y... en varias explicaciones ellos indicaban que lo hacían así por SRP. En fin! Saludos
@@SimaDamian Exacto Hector, el problema aquí es que los patrones de diseño son técnicas que resuelven ciertos problemas específicos de diseño, si no sufres alguno de esos problemas estarias haciendo un YAGNI al aplicar el patrón. Por ejemplo si aplicamos el patrón command sin la necesidad real de resolvernos un problema de manejar estados, encapsular comportamientos complejos, etc se puede transformar en el antipatron de "descomposicion funcional" ya que estariamos diseñando como una serie de llamadas a funciones y no como colaboración entre objetos, aunque estén representados en clases
Creo que es mas sencillo entender SRP desde un punto de vista funcional (de negocio, tecnico o de abstraccion). Donde la cohesion se mantiene porque cada metodo hace uso de todos o muchos de los atributos (lo que es un indicio de que se cumple SRP). La version de Dijkstra es mas intuitiva y natural, la definicion SRP de Uncle Bob es mas "retorcida"
¿Podrían hacer la vídeos de clean code ? Gracias!!
Ciertamente tenéis un nivel que es difícil seguiros, pero por otro lado, compensa con las ganas y entusiasmo que ponéis, con el buen rollo y lo ameno de los diálogos. Qué os enrolláis mucho a veces, sí, pero que importa eso, es vuestro estilo, lo hacéis gratis, compartiendo vuestros conocimientos a vuestra manera. Sinceramente, aplicar el principio de responsabilidad única para las críticas destructivas apartándolas de vuestro main y acoger los agradecimientos y críticas constructivas acoplándolas mucho a vosotros. Saludos cordiales
La verdad que sí. Llevo un año programando, y no entiendo ni la mitad de los temas que tocan (no es que esté muy orgulloso 😅). Creo que el problema está en las bases; tengo que frenar un poco mi flujo creativo, dejar de crear proyecto tras proyecto con nuevas tecnologías, respirar y ponerme a aprender paradigmas y patrones de diseño. Te aconsejo lo mismo 😉
Pense que era el unico, la verdad no entiendo muchas cosas de las que hablan, jajajajaja y llevo bastante programando hace 2 años y investigo a diestra y siniestra
Contenido solo orientado para comprar vuestros cursos, no digo que no sean buenos los cursos de pago, pero prefiero cuando la gente comparte su conocimiento sin un negocio detrás, solo con estos videos con vosotros no se puede aprender mucho, como bien dicen en otros comentarios el lenguaje y la forma que utilizáis es para gente muy avanzada
Y de que van a vivir, quien paga todos los recursos que usan para grabar y publicar?.... Y respecto a lo último, esa es la idea de ellos, ellos no hablan de cosas básicas (de eso hay harto en UA-cam) este es uno de los pocos canales que habla de cosas avanzadas en español
epale!
"Separation of concerns" se podría traducir como "separación de incumbencias"
O separación de asuntos :D
Debería renombrarse a SOR, Single Origin Rsponsability - Responsabilidad en Origen Única
En que parte pusieron los links de los recursos ?
Añadidos en la descripción! 😊
@@CodelyTV apenas se agregaron jaja
Hasta donde yo sé, los principios son principios, es decir, es a lo que tiene que tender tu código. Esto es así porque no DEBE de aplicarse siempre imperativamente. No lo convirtáis en un martillo de oro.
Otra cosa. ¿Qué opináis de utilizar partial classes para aplicar SRP?
La letra D, Para cuando lo cursos de Kotlin y Spring?
Seguís sin entender el principio, esperaré 6 años mas a ver si en el siguiente video ya lo habéis pillado.
¿Alguna fuente que lo explique mejor?
@@MaximoPower2024 busca Tom DeMarco y cohesión, que son las bases de este "principio"
¿Y los enlaces?
Añadidos en la descripción! 😊
@@CodelyTV 👍 No los había visto
hoal
un método de una linea con una respuesta es más fácil de testear
En lugar de tener un chorro de método, tienes varios haciendo una cosa cada uno, además fácilmente serán reusables.
Pues la "O" 😁
todas las letras
Nunca acabo de entender por qué dan dislike. Me da que es gente que se aburre y lo hace por hobby. Excelente vídeo
Qué por qué no se entiende la S de SOLID?? Pues porque se enseña mal y punto!
Porqué habláis siempre de SOLID, cuando no son los únicos principios que intentan resolver los problemas reales que son siempre los mismos, alto acoplamiento ,baja cohesión,...
Porque SOLID como acrónimo tiene mucho gancho, y ahora vivimos por y para eso. Pero en el fondo todo se reduce a los que destacas, un par de principios de diseño y docenas de patrones que intentan solucionar los casos donde se incumplen.
no entendi nada XD
Es el principio mas facil de entender
Gracias chicos, no lo entendía y ahora lo entiendo menos jaja...
Jim Coplien tenía toda la razón ante Uncle Bob la gente piensa que el tiene toda la verdad, mucho de lo que el cuenta es retazos de otras personas contadas a su manera. Si preguntan a 10 dev que son los principios de Uncle Bob cada uno tiene su versión lo cual te dice que lo que predica es flojo no debería quedar a subjetividad eso crea problemas al crear software.
Bueno imagino que no estas hablando de Liskov y Open Close por que seria una falta de respeto a Mayer y Barbara
@@marcosvitaliable DeMarco tambien se siente ofendido
Habláis de software en general pero luego repetís esa idea de que las clases solo deberían tener un punto de entrada. No me cuadra.
Muchachos son unos masters, quiero hacer algunos cursos, pero solo tengo paypal, habiliten paypal en su plataforma, nos dejan sin acceso a un grupo interesado.
En mi opinión, un módulo puede ser cualquier cosa:
librería, paquete, clase, método...
¿Qué entiendo por el principio de responsabilidad única? Organiza tus "cajas", y agrupa con sentido: En una caja de comida, guarda cajitas de carne y cajitas de frutas, pero no cajitas de productos de limpieza, a su vez en la cajita de frutas, guarda naranjas y guarda manzanas, pero no guardes filetes de ternera, y por último a una manzana, no le metas un método "exprimirFruta".
Puede parecer evidente y una tontería, pero estoy acostumbrado a ver métodos de "ayuda" que no tienen nada que ver con la razón de ser de la clase, y clases en paquetes que nada tienen que ver con la razón de ser del paquete.
Cada librería, paquete, clase, método...en resumen, cada "modulo", debe tener una única razón de ser, que puede ser más o menos genérica (eso depende de lo fino que hilemos, la arquitectura, y con que pie nos levantemos ese día), pero debe ser solo una, y su contenido debe ser coherente con dicha razón de ser.
Al menos, así es como yo lo veo :D
Desde mi punto de vista va por ese lado... no voy a comentar más al respecto porque ya lo he hecho en otro momento!
El único problema que le veo a SOLID, patrones de diseño y las abstracciones en general es el tiempo invertido humano en cualquier equipo y generalmente en toda la comunidad de developers en platicar como hacerlo de la manera correcta. La deuda técnica sigue acumulándose mientras hablamos de todo esto y en cada cabeza X abstracción debe de ser aplicada de tal manera u otra, todo es muy opinionado porque estamos hablando de conceptos, no de cosas concretas y como abordarlas. Nos perdemos horas de vida discutiendo sobre la forma correcta de hacer las cosas para que hagan click con las abstracciones y no con el dominio del problema, si tratar con el código espagueti era difícil, navegar en un mundo de abstracciones en donde nadie está de acuerdo es casi igual o peor. No quiere decir que esté en contra, pero he visto proyectos insufribles donde al tratar de aplicar los principios SOLID, el resultado fue bastante desastroso, se supone que el resultado era código extensible y mantenible, pero fue todo lo contrario, cualquier cambio era una tortura debido a que no hay un consenso. Con mesura y consenso pueden lograrse buenos resultados, pero tampoco son la panacea.
Me gustan estos videos pero os enrolláis cosa mala y los primeros 12 minutos no habéis dicho nada. Por favor id mas al grano.
a mi me cuesta más la L🤷♂️
¿Quieres que hagamos un vídeo sobre ello? 😊
@@CodelyTV estaría muy bien ver sus puntos de vista👂, yo creo que se deben explicar OClose y Liskov en el mismo vídeo ya que desde mi humilde opinion son la base del resto de principios🙂
@@CodelyTV shi
me he quedado como estaba jajajaja yo separo todo y a tomar por culo
La letra que me cuesta más es la del coche que me falta por pagar.
(perdón)
xDDDD
«La verdadera prueba del conocimiento no es la verdad, sino la utilidad».
Yuval Noah Harari
😒😒😒😒😒😩😩😩😩
La I de SOLID es la menos entendida, incluso por aquellos que creen saberlo. Es increíble la cantidad de programadores que no saben qué es Interface Segregation. Sin embargo es una de las más importantes.
Mucha habladuría pero explicar un concepto sin ejemplos, se pierde la idea que queres transmitir