Por qué no uso "Valores por Defecto" en mi código
Вставка
- Опубліковано 3 січ 2024
- Una de las primeras cosas que se aprenden programando es a utilizar valores por defecto, pero esto puede ser muy dañino.
Curso de Value Objects! bit.ly/curso-vo
﹤🍍﹥ Codely
├ 🎥 Suscríbete: ua-cam.com/users/CodelyTV?sub_co...
├ 🔖 Cursos: bit.ly/cursos-codely
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv - Наука та технологія
¿Usas valores por defecto?
En Frontend se usan un montón. Es muy común ver componentes que tienen una propiedad con múltiples valores y que tienen uno de esos valores por defecto
Una variable o propiedad no nullable debería tener un valor siempre.
Ya no 😂
Me parece muy bien el contenido pero no hay ejemplos con frameworks de frontend, en react como harías para que una prop no tenga un valor por defecto ?
@@LuisDa20Ahora hay que especificar los valores por defecto para cada una de las 25 props que recibe un componente de libreria. Muy util la API!
Pero es qaue es mas sencillo que eso, antes de poner un valor por defecto hay que pensar, no solo sentarse a codificar, poner una fecha de nacimiento con la fecha actual como valor por defecto es un mal razonamiento del programador. Hay casos donde si pueden ir facilmente y otros en los que no, y ese razonamiento viene aun antes de sentarse a codificar. No hay que buscarle 3 patas al gato sabiendo que tiene 4...
Si me parece que el ejemplo no es el mejor pero seria lo de menos, hace de cuenta que en vez de fecha de nacimiento es fecha de validacion o lo que sea.
@@bagocavsEl ejemplo es perfecto de hecho, porque permite ver como un valor por defecto debe razonarse antes de ponerlo. El ejemplo es tan absurdamente real.
El tema aqui es que todo depende de lo que se decida ya sea como desarrollador individual o en equipo y documentarlo. Mas de si vale la pena o no usarlos.
Creo que en este video no se explico miy bien lo de los valores por defecto, y el ejemplo no ayuda, porque el valor por defecto que tiene es un tanto incongruente
A veces la necesidad de usar parámetros con valor por defecto te hace plantearte quién debería ser el cliente de tu clase y si esa es su responsabilidad.
Muy interesante discusión, me ayuda un montón. gracias!
Geniales como siempre
La mejor frase: "Sensación de productividad. Done" jajaja
Una opcion para poder hacer resolver eso aunque ellos lo dicen es creando un 3er constructor, pero existe otras que son los famoso mappers o mapeadores, es basicamente una clase que tu creas llamese UserMapper donde creas un metodo abstracto y ahi te encargas de retornar una instancia de esa la clase principal llamese User y ahi haces las respectivas validaciones o valores por defecto en caso de que llegue null o no el valor deseado.
Y porq era q no es bueno usarlos? Les falta ser mas concisos.
ponga atención rey
Se mencionan varios puntos en el vídeo, son algo abstractos.
En general a futuro genera problemas de mantenibilidad de código, por lo que si el modelo de datos o el caso de uso cambia será un pain in the ass acomodar todo el código para que siga funcionando y no se incluyan bug.
Anyway: ponga atención x2 jaja
Pero es que no se entiende una...
muchas gracias
Si y de hecho hace poco lo use para un metodo de filtros en un repositorio. Entonces, pensaba si esto lo evitaria con el patron criteria
Vine a ver por qué no debería usar valores por defecto y de paso aprendí por qué no usar el constructor por defecto
Es cierto que un parámetro por defecto puede ser peligroso como se muestra en el ejemplo del vídeo, pero creo que es necesario explicarlo más en detalle.
En este caso concreto es malo, y es así porque el valor por defecto se encuentra en una clase de datos, su único propósito es ser un contendor de valores, por eso no tiene sentido que tenga valor por defecto, ya que los valores deberían venir de alguna base de datos o de algún formulario cuando se vaya a crear una instancia para almacenarla almacenar.
Pero en otros casos como clases que proveen algún tipo de funcionalidad o incluso funciones puede ser muy útil ya que en muchas ocasiones los valores que utilizamos en la mayoría de parámetros son siempre los mismos y tener que estar estableciendo cada valor de todos los parámetros siempre sería muy tedioso y repetitivo.
Sois unos frikis, pero muy simpáticos.
Básicamente no usar valores por defecto porque no confían en su propio criterio para establecerlos correctamente.
Me parece bien, los que no son capaces de utilizar una herramienta sin hacer desastres no deberían usarla.
Por otro lado, los que si pueden sacarle el jugo a esas cosas pues deberían usarlas con confianza
cual es el nombre de la fuente ?
Dank mono
Muy bien, pero deberíais plantear también eliminar esos metodos estáticos "create", ocultan las dependencias reales y evitan que se usen los value objects por toda la base de código. Nada como un buen y explicito "new".
Porque? no oculta ninguna dependencia "real", solo muestra lo que es escencial para el cliente y encapsula lo que no. Ademas lo de evitar el uso de value objects yo lo veo como un beneficio, delegas su creacion a esta clase y te olvidas
@@bagocavspor ejemplo si el string de email no es una dirección válida dónde deberíamos controlar ese error? En su value object UserEmail si no queremos incumplir SRP, creamos un metodo isValid() y comprobamos antes de pasarlo al new User(). Si metemos todo esto en User también estamos incumpliendo SRP, según yo lo veo. Al final si tienes una dependencia entre User y UserEmail no está de más que el "cliente" lo sepa para que pueda adaptarse a cualquier casuística, no sé si me explico... Otro beneficio de extraer los value objects es poder hacer refactoring con ellos y reutilizar código.
Es un static factory, so...
😢😢C# te obliga a inicializar valores por defecto si no son nullables.
Para eso son los constructores
Nop lo que hace C# es que te advierte que puede haber incongruencias con una propiedad que no se inicializa en el constructor
@@bagocavs y advertirte no es obligar? En C# las variables y propiedades que no sean nullables deben ser inicializadas si o si.
En realidad esa validación se puede desactivar
Me hace gracia que les chirrie un valor por defecto pero luego no chirrie usar parametros en lugar de un parametro con un type/clase/interfaz/... ¿Que vas a hacer cuando tu clase en lugar de ser un caso raro de 2 propiedades como son email y birtdate tengas 10-15-25 propiedades?
Dividirla 😬
@@CodelyTV Dividir pòr dividir creo que trae mas problemas que beneficios, por ejemplo un Pedido tiene información de metodos de pago, pago escogido , transportista escogido , cupones, info del producto en el momento que se hizo el pedido, totalizaciones, tasas, estados, información del cliente como el grupo al que pertenecia y el tipo de descuento que tenga ese grupo, por si cambia de b2c a b2b o de silver a platinum o lo que sea, etc...
Eso es una barbaridad de información y hasta cierto punto lo puedes dividir para tener bien estructurado el dato, pero el problema sigue estando ahi, mucho dato.
Puedes sacar ciertas cosas fuera del pedido, como etiquetas de transportista, información que te den las distintas plataformas de metodos de pago, los "intents", el carrito, información de ERP, información de SGA, shippings (nosotros estamos integrados con 24 empresas de transporte distintas, tu compras con un transportista genérico y lo enviamos de modo que haya un equilibrio y no nos cueste una pasta pero tampoco tarde en llegarte, de modo que puede hacerse en 2 viajes si fuese necesario, etc... porque sirven para "gestionar" la creación del pedido o para complementarlo una vez hecho pero no forman parte del pedido como tal. ¿Que haces 80 métodos estáticos para poner cada campo uno a uno?
Desde mi punto de vista un pedido es solo una materialización del carrito, coge lo que hay en el carrito, añade información extra del sistema (porque el nombre del transportista, producto, etc... podria cambiar y tu tienes que tener la foto de lo que pidio el tio, no de lo que hay en el sistema), calcula y guarda, no le veo beneficio alguno a tener un metodo con 80 campos uno detrás de otro ni le veo sentido a tener 80 metodos estáticos.
No lo digo en plan para criticar ni atacaros, pero estaria bien que alguna vez pusieseis de ejemplo un caso de uso tocho.
se entiende la idea, pero la verdad que lo habeis explicado un poco mal, y mucho desvario por las ramas pero bueno esta bien el video.
Muy mal ejemplo. Efectivamente ahí es mala idea. Pero el programador NO PUEDE ser tan idiota de poner un birthday por defecto. El problema puede ser una falta de actitud, no un "antipatrón"
Un mejor ejemplo: class Log. ¿Es un antipatrón poner timestamp por defecto? Yo diría que no, pero puedo entender de que si se trata de sistemas distribuidos, quizá lo mejor es obligar a pasar el atributo.
No entendí un carajo.