Cambie un poco la logica para el modelo:
package dto type Pokemon struct { Id int `json:"Id"` Name string `json:"Name"` Type string `json:"Type"` Stats Stats `json:"Stats"` } type Stats struct { Hp int `json:"Hp"` Attack int `json:"Attack"` Defense int `json:"Defense"` Speed int `json:"Speed"` } func (s *Pokemon) SetAbilities(nameStat string, valueStat int) { switch nameStat { case "hp": s.Stats.Hp = valueStat break case "attack": s.Stats.Attack = valueStat break case "defense": s.Stats.Defense = valueStat break case "speed": s.Stats.Speed = valueStat break } }
y aqui la forma de utilizarlo dentro de la funcion ParsePokemon:
pokemonResponse := dto.Pokemon{ Id: apiPokemon.Id, Name: apiPokemon.Name, Type: apiPokemon.PokemonType[0].RefType.Name, } for _, stat := range apiPokemon.Stats { pokemonResponse.SetAbilities(stat.Stat.Name, stat.BaseStat) } return pokemonResponse, nil
Sebastian Aranda
Interesante el curso, sin embargo para futuras mejoras, siempre el README file debe contener la información básica de cualquier repositorio o proyecto. Es bueno tener las buenas practicas desde el inicio.
Rubens A. Rangel Gomez
🧠 Idea principal
No basta con que el código funcione o pase tests; también debe estar bien estructurado, ser entendible y seguir buenas prácticas desde el inicio.
🧩 Fundamentos
1. Documentación (README)
2. Buen modelado de datos
Pokemon y Stats) mejora claridad.3. Encapsulación de lógica
SetAbilities controlan cómo se modifican los datos.4. Transformación de datos (parser)
5. Aprendizaje continuo
🔑 Puntos importantes
🎯 Conclusión corta
Código que funciona no siempre es buen código. La calidad también está en cómo está organizado, documentado y pensado.