Soy programador Java y con la entrada de la programación funcional, las «malas practicas» son más evidentes en un entornos funcional.
Obviamente esto es una visión personal. Seguramente tengas todo lo que necesitas y sepas todo lo necesario para poder hacer aplicaciones que funcionan cómo funcionalmente deberían.
Pero me gustaría darte otro punto de vista cuando te plantees picar un switch case o un if else if
Hace relativamente poco, empecé con golang y el ejemplo esta picado en este lenguaje, pero es posible hacerlo en cualquier lenguaje.
Imaginaros un switchase:
Qué implica esta estructura ?. Cada vez que tengas que añadir un caso mas, tendrás que expandir el bloque haciendo cada vez este fichero/clase, cada vez más grande. Ahora imaginaros un switch case de una calculadora de alguien que empieza a programar:
case 1 add: case 2 must, etc…
Qué escalabilidad podría tener ? tanta como el fichero pueda albergar.
Una calculadora cutre como esta, no tendrá mucha lógica en los casos, pero si es algo mucho mas complejo: llamadas a métodos, variables, retornos, etc …
Si cambiáis este switch case, este ifelseif eterno, por un map que contenga el nombre/id de la acción y la propia acción, la complejidad es O(1), no evalúa si puede entrar en casa caso o no (depende del lenguaje).
En el caso anterior, la definición esta todo dentro del mismo fichero, pero podéis separar, estas funciones y añadir complejidad en una estructura aislada, dando la posibilidad de que el código se pueda escalar y mantener de una manera más cómoda.
package main
import "fmt"
func main() {
actions := make(map[string]func(a int, b int) int)
actions["add"] = func(a int, b int) int { return a + b }
actions["sub"] = func(a int, b int) int { return a - b }
actions["mult"] = func(a int, b int) int { return a * b }
fmt.Println(actions["sub"](1, 2))
fmt.Println(actions["add"](3, 5))
fmt.Println(actions["mult"](3, 3))
}Ojo, este no es la única forma de evitar este «problema» a la hora de pogramar