1
00:00:00,720 --> 00:00:06,000
Hola a todos, en este video
hablaremos sobre la campaña Anti-IF.

2
00:00:06,480 --> 00:00:09,480
En particular, explicaremos
los motivos por los que

3
00:00:09,920 --> 00:00:13,720
retornar y verificar por nil
no es bueno.

4
00:00:13,920 --> 00:00:18,520
Aquí hay un ejemplo de un código,
que no es un objeto.

5
00:00:19,040 --> 00:00:21,680
Su parámetro de método es un animal.

6
00:00:21,880 --> 00:00:24,680
Sus acciones varían
de acuerdo con el animal.

7
00:00:24,880 --> 00:00:30,560
Por ejemplo, podemos pedir a un perro
que mueva su cola o un pato que grazne.

8
00:00:31,000 --> 00:00:33,440
Para un gato, solicitamos otras acciones.

9
00:00:34,040 --> 00:00:38,080
Entonces, ¿por qué es problemático?
para usar declaraciones de If?

10
00:00:39,120 --> 00:00:43,800
Particularmente cuando se usan
para verificar el tipo de receptor.

11
00:00:45,080 --> 00:00:49,200
Por ejemplo, si queremos agregar
un nuevo animal aquí,

12
00:00:49,360 --> 00:00:53,400
tendríamos que verificar
todo el código del proyecto

13
00:00:53,680 --> 00:00:56,880
para buscar declaraciones If.
que puedan aplicar.

14
00:00:57,040 --> 00:01:01,280
Tendríamos que modificar
numeroso código en todo el proyecto.

15
00:01:01,640 --> 00:01:06,560
Además, agregar casos a métodos
los hace engorrosos,

16
00:01:06,840 --> 00:01:10,440
y se pierden
en demasiados detalles.

17
00:01:10,720 --> 00:01:13,760
Agregar animales
hace que este método sea muy largo,

18
00:01:13,920 --> 00:01:17,160
y cada tipo de animal
puede tener muchos detalles.

19
00:01:17,320 --> 00:01:21,760
Incluso por una característica simple,
como que no todos los perros tienen colas,

20
00:01:21,920 --> 00:01:25,920
tendríamos que crear
casos separados para cada opción.

21
00:01:26,120 --> 00:01:31,640
El código se convertiría en
complicado y más difícil de entender.

22
00:01:32,240 --> 00:01:35,760
Entonces, para reemplazar estas
acciones, enviamos mensajes.

23
00:01:36,080 --> 00:01:38,480
Este es un punto que seguimos reiterando.

24
00:01:38,640 --> 00:01:42,240
El punto clave para recordar
es el envío de mensajes.

25
00:01:42,880 --> 00:01:46,280
Podemos reemplazar
el código anterior con este.

26
00:01:47,040 --> 00:01:51,160
Aplica el método showHappiness
en cada clase relevante.

27
00:01:51,320 --> 00:01:56,480
Cada clase decidirá cómo cada animal
mostrará su "felicidad".

28
00:01:56,760 --> 00:02:02,720
Para cada animal, todo lo que necesitamos hacer
es enviar el mensaje

29
00:02:05,560 --> 00:02:07,560
showHappiness al animal,

30
00:02:08,600 --> 00:02:11,360
y uno de sus métodos se ejecutará.

31
00:02:11,520 --> 00:02:15,040
Vemos aquí que Pharo
está haciendo la función If.

32
00:02:15,200 --> 00:02:19,960
Pharo decide qué método aplicar
a un tipo particular de animal.

33
00:02:20,120 --> 00:02:22,920
Esto se ejecuta automáticamente.

34
00:02:23,120 --> 00:02:27,480
No hay necesidad para nosotros
para especificar Ifs para tipos de objetos.

35
00:02:28,040 --> 00:02:31,200
Solo hace códigos
menos coherentes y dinámicos.

36
00:02:32,560 --> 00:02:36,040
Ahora hablaremos
el caso específico de Nil.

37
00:02:36,440 --> 00:02:39,160
Si un método devuelve nil,

38
00:02:39,320 --> 00:02:43,120
usted obligará a sus clientes
para usar sentencias If.

39
00:02:43,280 --> 00:02:46,200
Considerando que raramente se recomienda usar If.

40
00:02:47,520 --> 00:02:50,520
Aquí utilizamos un ejemplo de un código

41
00:02:50,760 --> 00:02:55,440
basado en un parámetro y una inferencia.

42
00:02:55,600 --> 00:02:57,880
El tipo de código no es importante.

43
00:02:58,160 --> 00:03:01,440
Aquí vemos que en algunos casos,
se devuelve nil.

44
00:03:01,840 --> 00:03:04,480
Esto significa que cuando usamos este código,

45
00:03:04,760 --> 00:03:08,600
tenemos que verificar
el mensaje rulesForFact.

46
00:03:08,800 --> 00:03:11,480
¿Retornó rulesForFact nil?

47
00:03:11,680 --> 00:03:14,560
Actuamos de manera diferente
dependiendo de la respuesta.

48
00:03:14,720 --> 00:03:17,280
Vemos que en este caso,

49
00:03:17,880 --> 00:03:20,280
ya que estamos usando un término plural,

50
00:03:20,440 --> 00:03:23,960
el método probablemente
devuelve una colección.

51
00:03:24,200 --> 00:03:26,880
Una solución efectiva para evitar nil

52
00:03:27,080 --> 00:03:31,000
en esta situación
es devolver una colección vacía.

53
00:03:31,200 --> 00:03:33,080
Esto funciona en muchos casos.

54
00:03:33,400 --> 00:03:38,520
Devolviendo una colección vacía
en lugar de cero, simplifica el código.

55
00:03:38,880 --> 00:03:42,400
Porque los clientes simplemente pueden
iterar la colección,

56
00:03:42,560 --> 00:03:45,360
y si está vacío, no sucederá nada.

57
00:03:46,480 --> 00:03:48,400
Para casos excepcionales,

58
00:03:48,840 --> 00:03:52,360
como cuando tienes una transmisión de archivo

59
00:03:52,520 --> 00:03:56,320
que no se ha abierto para escribir
y muestra un error,

60
00:03:56,560 --> 00:04:01,640
en lugar de retornar nil, informamos
al sistema al levantar una excepción.

61
00:04:01,920 --> 00:04:05,600
En Pharo,
llamamos a esto lanzar una excepción.

62
00:04:05,760 --> 00:04:09,560
Creamos una instancia
de la clase o subclase de excepción

63
00:04:09,720 --> 00:04:11,960
y enviamos el mensaje "signal".

64
00:04:13,680 --> 00:04:19,640
Esto evita obligar
el cliente del método nextPutAll

65
00:04:19,800 --> 00:04:23,960
verificar si es nil,
cuando es probable que haya ocurrido un problema.

66
00:04:24,200 --> 00:04:26,800
O bien el cliente maneja la excepción

67
00:04:26,960 --> 00:04:31,680
o se maneja
por el cliente del cliente, y así sucesivamente.

68
00:04:31,880 --> 00:04:37,840
Podemos centrarnos en un nivel específico
para capturar la excepción.

69
00:04:38,560 --> 00:04:40,240
Evita el uso excesivo de Ifs.

70
00:04:40,880 --> 00:04:45,720
Otro caso en el que encontramos
chequeos por nil

71
00:04:45,880 --> 00:04:49,280
es en variables de instancia
que no se inicializan.

72
00:04:49,600 --> 00:04:54,800
Si un código dice que si la variable
es todavía nil, debe reaccionar de cierta manera,

73
00:04:54,960 --> 00:04:59,200
es mejor inicializar la variable
inmediatamente,

74
00:04:59,360 --> 00:05:01,960
con un valor que funciona para todos los casos.

75
00:05:02,120 --> 00:05:03,120
Por lo tanto, aquí,

76
00:05:03,600 --> 00:05:06,680
para "members"
que contiene una colección,

77
00:05:06,840 --> 00:05:10,600
inicializamos una colección vacía
en lugar de usar nil.

78
00:05:10,920 --> 00:05:13,520
Una vez más, esto a menudo funciona bien.

79
00:05:13,960 --> 00:05:18,000
Si quieres dar un valor
a una variable,

80
00:05:18,400 --> 00:05:22,680
y si es costoso
para calcular su valor,

81
00:05:22,840 --> 00:05:26,560
puedes esperar hasta el último momento
para calcularlo.

82
00:05:26,720 --> 00:05:30,520
Puede que nunca se calcule,
por lo que ahorra tiempo de ejecución.

83
00:05:31,320 --> 00:05:35,040
En esos casos,
usamos la inicialización perezosa.

84
00:05:35,200 --> 00:05:38,280
Esto se usa cuando se requiere un valor.

85
00:05:38,680 --> 00:05:42,400
Si el valor sigue siendo nil,
le asignamos un valor.

86
00:05:42,560 --> 00:05:47,240
Si ya no es nil,
devolvemos su valor de inmediato.

87
00:05:48,000 --> 00:05:52,600
Aquí tenemos un If asociado con nil,
pero solo tenemos uno.

88
00:05:53,160 --> 00:05:57,920
Todos los demás usuarios de la variable
utilizar el método de acceso,

89
00:05:58,520 --> 00:06:00,720
y no deben verificar si es nil.

90
00:06:01,320 --> 00:06:03,960
A veces encontramos casos

91
00:06:04,520 --> 00:06:09,840
en el que es necesario verificar
si tenemos que responder o no.

92
00:06:10,320 --> 00:06:12,160
Como vemos en este ejemplo.

93
00:06:12,800 --> 00:06:15,840
Aquí tenemos una ToolPalette.

94
00:06:16,120 --> 00:06:19,440
Si se selecciona una herramienta,
podemos responder,

95
00:06:19,600 --> 00:06:22,960
pero si no se selecciona ninguno,
preferimos no actuar.

96
00:06:23,640 --> 00:06:26,480
Mire la función selectedTool.

97
00:06:26,720 --> 00:06:31,600
Si devuelve nil, no se seleccionan herramientas,
por lo que no se requiere ninguna acción.

98
00:06:31,800 --> 00:06:35,760
Si selectedTool devuelve algo,

99
00:06:36,000 --> 00:06:40,080
le pediremos que realice una acción.

100
00:06:41,040 --> 00:06:42,920
Una buena forma de reemplazar esto

101
00:06:43,360 --> 00:06:45,720
es usar el patrón NullObject.

102
00:06:45,880 --> 00:06:50,400
En lugar de tener dos casos,
uno con herramientas y otro sin herramientas,

103
00:06:50,600 --> 00:06:54,440
tenemos un caso
en el que una de nuestras herramientas no hace nada.

104
00:06:54,600 --> 00:06:57,120
Esta herramienta se seleccionará de manera predeterminada.

105
00:06:57,360 --> 00:07:01,840
Creamos una herramienta que no hace nada
cuando se le pide que realice acciones.

106
00:07:03,120 --> 00:07:09,000
En lugar de no seleccionar nada,
habilitamos una herramienta que no hace nada.

107
00:07:10,360 --> 00:07:14,800
Para obtener más información sobre NullObject,
mira estas referencias

108
00:07:15,680 --> 00:07:16,840
En conclusión,

109
00:07:17,000 --> 00:07:19,640
los mensajes son más efectivos que los Ifs.

110
00:07:19,840 --> 00:07:22,520
Utilizará Ifs en ciertos casos,

111
00:07:22,680 --> 00:07:27,680
pero a menudo puede evitar usarlo
y envíe mensajes en su lugar.

112
00:07:28,840 --> 00:07:34,160
Evita retornar nil porque
te obliga a insertar chequeos con IFs

113
00:07:34,360 --> 00:07:38,280
para saber si el valor
es o no nil.

114
00:07:39,440 --> 00:07:44,720
Inicializa variables ya sea en la creación
o usando la inicialización perezosa.

115
00:07:45,680 --> 00:07:50,760
Crea objetos que representan el comportamiento
predeterminado o la ausencia del mismo.

116
00:07:50,960 --> 00:07:54,960
Esto se aplica no solo a Pharo
sino a todos los lenguajes de objetos.

117
00:07:55,200 --> 00:08:00,840
Es importante recordar estos puntos.
sea ​​cual sea el lenguaje que uses.