Hola a todos, en este video hablaremos sobre la campaña Anti-IF.
En particular, explicaremos los motivos por los que
retornar y verificar por nil no es bueno.
Aquí hay un ejemplo de un código, que no es un objeto.
Su parámetro de método es un animal.
Sus acciones varían de acuerdo con el animal.
Por ejemplo, podemos pedir a un perro que mueva su cola o un pato que grazne.
Para un gato, solicitamos otras acciones.
Entonces, ¿por qué es problemático? para usar declaraciones de If?
Particularmente cuando se usan para verificar el tipo de receptor.
Por ejemplo, si queremos agregar un nuevo animal aquí,
tendríamos que verificar todo el código del proyecto
para buscar declaraciones If. que puedan aplicar.
Tendríamos que modificar numeroso código en todo el proyecto.
Además, agregar casos a métodos los hace engorrosos,
y se pierden en demasiados detalles.
Agregar animales hace que este método sea muy largo,
y cada tipo de animal puede tener muchos detalles.
Incluso por una característica simple, como que no todos los perros tienen colas,
tendríamos que crear casos separados para cada opción.
El código se convertiría en complicado y más difícil de entender.
Entonces, para reemplazar estas acciones, enviamos mensajes.
Este es un punto que seguimos reiterando.
El punto clave para recordar es el envío de mensajes.
Podemos reemplazar el código anterior con este.
Aplica el método showHappiness en cada clase relevante.
Cada clase decidirá cómo cada animal mostrará su "felicidad".
Para cada animal, todo lo que necesitamos hacer es enviar el mensaje
showHappiness al animal,
y uno de sus métodos se ejecutará.
Vemos aquí que Pharo está haciendo la función If.
Pharo decide qué método aplicar a un tipo particular de animal.
Esto se ejecuta automáticamente.
No hay necesidad para nosotros para especificar Ifs para tipos de objetos.
Solo hace códigos menos coherentes y dinámicos.
Ahora hablaremos el caso específico de Nil.
Si un método devuelve nil,
usted obligará a sus clientes para usar sentencias If.
Considerando que raramente se recomienda usar If.
Aquí utilizamos un ejemplo de un código
basado en un parámetro y una inferencia.
El tipo de código no es importante.
Aquí vemos que en algunos casos, se devuelve nil.
Esto significa que cuando usamos este código,
tenemos que verificar el mensaje rulesForFact.
¿Retornó rulesForFact nil?
Actuamos de manera diferente dependiendo de la respuesta.
Vemos que en este caso,
ya que estamos usando un término plural,
el método probablemente devuelve una colección.
Una solución efectiva para evitar nil
en esta situación es devolver una colección vacía.
Esto funciona en muchos casos.
Devolviendo una colección vacía en lugar de cero, simplifica el código.
Porque los clientes simplemente pueden iterar la colección,
y si está vacío, no sucederá nada.
Para casos excepcionales,
como cuando tienes una transmisión de archivo
que no se ha abierto para escribir y muestra un error,
en lugar de retornar nil, informamos al sistema al levantar una excepción.
En Pharo, llamamos a esto lanzar una excepción.
Creamos una instancia de la clase o subclase de excepción
y enviamos el mensaje "signal".
Esto evita obligar el cliente del método nextPutAll
verificar si es nil, cuando es probable que haya ocurrido un problema.
O bien el cliente maneja la excepción
o se maneja por el cliente del cliente, y así sucesivamente.
Podemos centrarnos en un nivel específico para capturar la excepción.
Evita el uso excesivo de Ifs.
Otro caso en el que encontramos chequeos por nil
es en variables de instancia que no se inicializan.
Si un código dice que si la variable es todavía nil, debe reaccionar de cierta manera,
es mejor inicializar la variable inmediatamente,
con un valor que funciona para todos los casos.
Por lo tanto, aquí,
para "members" que contiene una colección,
inicializamos una colección vacía en lugar de usar nil.
Una vez más, esto a menudo funciona bien.
Si quieres dar un valor a una variable,
y si es costoso para calcular su valor,
puedes esperar hasta el último momento para calcularlo.
Puede que nunca se calcule, por lo que ahorra tiempo de ejecución.
En esos casos, usamos la inicialización perezosa.
Esto se usa cuando se requiere un valor.
Si el valor sigue siendo nil, le asignamos un valor.
Si ya no es nil, devolvemos su valor de inmediato.
Aquí tenemos un If asociado con nil, pero solo tenemos uno.
Todos los demás usuarios de la variable utilizar el método de acceso,
y no deben verificar si es nil.
A veces encontramos casos
en el que es necesario verificar si tenemos que responder o no.
Como vemos en este ejemplo.
Aquí tenemos una ToolPalette.
Si se selecciona una herramienta, podemos responder,
pero si no se selecciona ninguno, preferimos no actuar.
Mire la función selectedTool.
Si devuelve nil, no se seleccionan herramientas, por lo que no se requiere ninguna acción.
Si selectedTool devuelve algo,
le pediremos que realice una acción.
Una buena forma de reemplazar esto
es usar el patrón NullObject.
En lugar de tener dos casos, uno con herramientas y otro sin herramientas,
tenemos un caso en el que una de nuestras herramientas no hace nada.
Esta herramienta se seleccionará de manera predeterminada.
Creamos una herramienta que no hace nada cuando se le pide que realice acciones.
En lugar de no seleccionar nada, habilitamos una herramienta que no hace nada.
Para obtener más información sobre NullObject, mira estas referencias
En conclusión,
los mensajes son más efectivos que los Ifs.
Utilizará Ifs en ciertos casos,
pero a menudo puede evitar usarlo y envíe mensajes en su lugar.
Evita retornar nil porque te obliga a insertar chequeos con IFs
para saber si el valor es o no nil.
Inicializa variables ya sea en la creación o usando la inicialización perezosa.
Crea objetos que representan el comportamiento predeterminado o la ausencia del mismo.
Esto se aplica no solo a Pharo sino a todos los lenguajes de objetos.
Es importante recordar estos puntos. sea ​​cual sea el lenguaje que uses.