Así dejé de hacer código spaghetti

[@JairoBum]

No seas maleducado es forma mas preciosa de verlo y hasta hora me entero... Por fin lo entiendo, gracias !!!!

[@ProductCrafter]

Jajaja, me alegro de que te haya gustado! Gracias a ti por comentar!

[@ReymarMend]

Hermosa metáfora, brillante

[@OmarAngaritaJ]

No había entendido del todo la ley de demeter pero con la analogía de "no seas maleducado" quedó muy claro todo. Excelente

[@ProductCrafter]

Gracias! Me alegro de que te haya servido 🙌

[@davidag90]

Buena analogía y un lindo concepto para emplear. Un poco en la línea de esa premisa que establece que las propiedades de los objetos no deben ser accedidas directamente (sobre todo desde fuera), sino que deben contar con métodos de consulta, seteo y modificación. Gracias por compartir!

[@ProductCrafter]

Gracias a ti por el comentario!

[@spaniard13]

En resumen, no te debes demeter donde no te llaman.

[@ProductCrafter]

😂😂😂😂😂😂

[@BhEaN]

Me ha encantado la metáfora de coger la cartera del cliente para quitarle el dinero diréctamente XDDD... muy buena explicación. Únicamente creo que hubiera quedado mucho más completo si de verdad hubieras definido unos interfaces previamente, ya que aunque se presupone que los estas usando, realmente no es así... solo has llamado a unos métodos que has ido definiendo sobre la macha. Se entiende perfectamente a lo que te refieres, pero quizás hubiera quedado más claro el concepto de esa forma. Saludos!!

[@ProductCrafter]

Le doy una vuelta para la próxima vez 🤔 Gracias por comentar!

[@marlonrugama2148]

Casualmente estoy trabajando en una aplicación modular que conlleva crear interfaces e implementación. Tienes que lidiar con control de acceso y otras técnicas. A simple vista es más trabajo y sí que lo es, pero a largo plazo el proyecto resulta bien organizado, escalable, modular y separación de responsabilidades. Cuando tienes los módulos separados puedes reutilizarlos y crear un nuevo feature se vuelve más rápido y fácil. Pero el inicio es doloroso sin duda alguna.

[@ProductCrafter]

Como dices es un trade off, al final cambias algo de velocidad al principio por agilidad después. Gracias por comentar!

[@johnclaius1091]

Vine buscando cobre y he encontrado oro! Excelente material!

[@ProductCrafter]

Gracias!!

[@odoncm]

Que chulos todos estos métodos de funcionamiento que explicas, me encantan!!!! Gracias.

[@ProductCrafter]

Me alegro! Muchas gracias!! 🙌

[@wiskys98]

Una analogía espectacular! Muy buen video, esperando ya el siguiente 😁

[@ProductCrafter]

Gracias! 🙌 El lunes o así subiré otro jaja

[@robertomorandeiraaparicio1595]

Muy buen ejemplo! Hay una bug en el cambio en la wallet. Comprueba si tiene más dinero de forma estricta, con lo que si la cantidad es 100 dirá que no, cuando en realidad sí que tiene suficiente dinero, quedándose a cero. Un saludo!

[@ProductCrafter]

Buen ojo! Gracias por comentar y avisar del fallo!!

[@ezequielbitschin6832]

Muy bueno!! Estaría genial si subís algún video abordando un poco los problemas que trae aplicar ésta ley estrictamente (por ej. Tell, don't ask -> explosión de métodos) y formas de abordarlos (por ej. usando inyección de dependencias / interface segregation) buscando algún punto de equilibrio. Gracias por el gran contenido ;)

[@ProductCrafter]

Me parece muy interesante! Lo apunto a la lista que tengo de videos para revisar! Gracias por la sugerencia! ❤️

[@ZorMon]

Lo mejor para evitar caer en este error es hacer siempre por defecto todas las propiedades de una clase privadas. Luego ya si necesitamos hacer pública una por alguna razón, pues la hacemos, y si el lenguaje lo permite, mejor aún hacerla readonly para asegurarnos de que se no se modifique desde fuera.

[@busters.20]

Muy buena explicación

[@ProductCrafter]

Gracias! 🙌

[@jeanpitech]

Excelente maestro!!

[@yousef-xyz]

Que hermoso es un codigo bien refactorizado ❤

[@edwinfajardo2135]

Los principipios SOLID en acción

[@juancarlospizarromendez3954]

Naturalmente, la caja electrónica dirá, "A pagar: X". A la cajera no le interesa si hay o no hay dinero en el monedero del comprador, ni las tarjetas de crédito/débito que podría tener, etc. Si el comprador no puede pagar X a la cajera entonces se complicará el trato, y por eso está la POO para intentar continuar el protocolo del impago.

[@Daath1990]

Yo lo conozco más por uno de los principios de base de datos: "Déjale al Cesar de lo que es del Cesar, por algo es el emperador de Roma"

[@ProductCrafter]

No lo había escuchado nunca! 🤔

[@MrSurinen]

excelente video excelente barba

[@ProductCrafter]

Jajajajajjaja ❤️

[@HorelvisCastilloMendoza]

Yo siempre lo he conocido por encapsulamiento y aislamiento entre clases

[@ProductCrafter]

Son conceptos relacionados sí!

[@IgnaDevPokemon]

Gracias por este contenido

[@Emanuel-yb3qk]

Bua brother, muchas gracias por esto.

[@ProductCrafter]

Gracias a ti!

[@alexdevorigin1]

Excelente explicación.

[@ProductCrafter]

Gracias!

[@TheLaiKash]

Muy buen consejo! No te das cuenta de esto hasta que tienes que refactorizar un código y cambiar 8000 lineas de código que accedían a un atributo de una clase chiquitita, por ejemplo. De este modo solo tienes que cambiar la implementacion de la clase chiquitita siempre y cuando devuelva el mismo tipo que antes. También ayuda a que no todo esté accesible por otras partes del código y a hacer más legible todo, algo así como los getter y setter en Java (creo que en python se hacen con @property y @attribute.setter). Muy buenos estos mini-tips en vídeos chiquitos!

[@ProductCrafter]

Me suena ese tipo de refactor 😅 No es divertido jaja

[@elcaza1119]

Excelente video!

[@ProductCrafter]

Gracias!!

[@JardanySvidrigailov]

Me encanto la metáfora

[@ProductCrafter]

Gracias!!

[@kaitenague]

bueno, python tampoco fué pensado para hacer código empresarial de gran calidad, es más orientado a glue code y srcipting aunque lo usen mucho los matemáticos para hacer cosas rápido.

[@ProductCrafter]

Todos sabemos como es Python 😂 Pero es que es súper versátil jaja

[@Santana-900]

Esto en el mundo real no crees que complica mucho el desarrollo. Piensa que has creado 4 métodos, métodos que seguramente se vayan a repetir varias veces porque hay sistemas enormes donde no te vas a acordar que ya hiciste algo parecido en otro lado. En mi caso trabajo con Odoo y me cuesta ver como podría aplicar esta lógica en un sistema tan grande Pd: Me ha encantado el vídeo, tienes un nuevo subs

[@ProductCrafter]

Al final es un trade-off. Es tener estos métodos o el día que cambie la wallet tener que tocar en 1000 sitios. Si la wallet la usas poco y está controlada (es poco volátil) puedes aceptar el trade off de no abstraerla. Todo "depende" en el desarrollo jajaja. Gracias por el comentario!!

[@FranciscoAntilef-h9g]

Me encanto la explicacion , pero siento que sigue rompiendo la ley de demeter al preguntar si posees el amount, no deberia solicitar el pago y en caso de NO contener suficiente amount la wallet deberia levantar una excepcion de dominio(la cual no esta creada en el ejemplo por simplicidad, asumo)?? saludos

[@ProductCrafter]

Siii! Pero eso que mencionas es el principio de "tell don't ask", que está muy muy relacionado con la ley de demeter pero no son la misma cosa exactamente. Pero me encanta que hayas visto intuitivamente que le fallaba algo! Eso muestra que escribes código como toca 🙌. Miraré de hacer un video de ese principio o de los dos juntos, gracias por el comentario!!

[@firielcasselius4033]

De pronto me siento inteligente porque siempre he puesto mis atributos como private, uso metodos para todo.

[@ProductCrafter]

Perfecto entonces! Bien encapsulado

[@franklynt2351]

saludos amigo creo el concepto es mas apropiado a una validación que a a no producir código espaguett las buenas practicas como la explicas la evitasi es la manera de hacerlo correctamente pero el titulo es confuso al aplicarlo

[@ProductCrafter]

Gracias por el feedback! Si que es verdad que puede llevar a equivocación. Le buscaré otro mejor! Gracias!

[@mayonesaka]

La ley de Demeter hasta meter xDDDDD ya me voy, Un saludo!!!!

[@ProductCrafter]

😂😂😂

[@jonathaneugeniosandovalmar2391]

Siento que estudio y no logro consolidar todos los conocimientos

[@ProductCrafter]

Poco a poco! La mejor forma de consolidar las cosas es aplicándolas, desarrollar es algo que se aprende mucho haciendo, así que dale tiempo y poco a poco va mejorando todo! Gracias por comentar!

[@JoSe086]

Wallet debería ser un paymentMethod inyectado (por qué wallet y no credit card?) con un único método pay que contenga dentro la lógica para realizar el pago (que puede ser distinta según el método de pago, conectarse al banco, a paypal…) y devolver el resultado de la operación. De la manera que lo has presentado hay muchísimo acoplamiento todavía porque manejas la lógica de Wallet dentro de la clase Customer. El título es “como dejé de hacer código spaguetti” pero esto sigue siendo bastante spaguetti 😅 (lo siento)

[@ProductCrafter]

Totalmente cierto!! El objetivo del video era mostrar la ley de demeter, el lunes subo un video partiendo de este explicando el principio de "tell don't ask" donde comento los problemas que comentas, pero en vez de inyectar el método de pago he optado por un customer.pay() que hace un wallet.pay() y wallet ya sabe como pagar. Gracias por el feedback! Si ves algo que tampoco te convence del video del lunes dime! Lo aprecio mucho 🙌

[@hawkapparel]

Buena info!

[@_DT_]

dentro de Wallet yo tendria los metodos get_money_amount() y set_money_amount() y como tu dices. dentro de esas funciones validaria si me llega el tipo de dato correcto.