No uséis switch case / No uséis infinitos if else if

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:

imagen de: https://www.wikitechy.com/tutorials/golang/golang-if

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

Deja una respuesta

A %d blogueros les gusta esto: