1
00:00:00,440 --> 00:00:02,600
Hola. En la sesión anterior,

2
00:00:02,760 --> 00:00:06,880
vimos cómo implementar
los booleanos: not y or

3
00:00:07,040 --> 00:00:11,960
Estaba pendiente la tercera pregunta:
¿Por qué diablos hicimos estas preguntas?

4
00:00:12,120 --> 00:00:13,880
Eso es lo que vamos a estudiar.

5
00:00:14,760 --> 00:00:20,120
Repasemos la implementación.
Para not, había dos objetos.

6
00:00:20,280 --> 00:00:22,400
Teníamos true y false.

7
00:00:22,560 --> 00:00:25,440
Eran instancias
de las clases True y False.

8
00:00:25,600 --> 00:00:27,200
Cuando enviamos un mensaje not,

9
00:00:27,360 --> 00:00:31,640
preguntamos a sus respectivas clases
y ejecutamos los métodos.

10
00:00:32,560 --> 00:00:34,080
Entonces, no tenemos problema aquí.

11
00:00:35,120 --> 00:00:37,240
Como ya he dicho,

12
00:00:37,400 --> 00:00:39,720
si mira lo que está haciendo:

13
00:00:39,880 --> 00:00:42,920
Primero, deja que el receptor decida.

14
00:00:43,080 --> 00:00:46,080
Significa que no toma ninguna decisión,

15
00:00:46,240 --> 00:00:49,320
usted envía un mensaje
que se resolverá por sí mismo.

16
00:00:49,480 --> 00:00:53,840
Entonces, estas dos funciones heurísticas eran:
deje que decida el receptor;

17
00:00:54,000 --> 00:00:57,320
y no pregunte sino diga que hacer.

18
00:00:57,480 --> 00:00:58,960
Voy a mencionar esto nuevamente.

19
00:00:59,120 --> 00:01:02,480
Ahora echemos un vistazo al ejercicio en sí.

20
00:01:03,080 --> 00:01:04,720
Entonces, ¿que es lo que ilustra?

21
00:01:04,880 --> 00:01:08,240
Nunca implementara booleanos.
en su vida,

22
00:01:08,400 --> 00:01:10,080
por lo menos eso espero.

23
00:01:10,240 --> 00:01:13,000
¿Es realmente inútil?

24
00:01:13,160 --> 00:01:15,920
¿Cuáles son las lecciones subyacentes?

25
00:01:16,080 --> 00:01:19,240
Creo que es muy importante
de hacerse esta pregunta:

26
00:01:19,400 --> 00:01:23,600
Sí, la implementación es así,
pero, ¿que ilustra?

27
00:01:24,560 --> 00:01:29,360
De hecho, se ve
que cada vez que envío un mensaje,

28
00:01:29,520 --> 00:01:33,640
cada vez que envío un mensaje,
Tengo algún tipo de sentencia case.

29
00:01:35,000 --> 00:01:38,800
Que encontrará
en programación C, etc.

30
00:01:39,880 --> 00:01:42,840
Enviando un mensaje
Realiza una elección múltiple.

31
00:01:44,160 --> 00:01:46,880
Lo que es interesante es:
cuando envía un mensaje,

32
00:01:47,040 --> 00:01:50,720
al final, es más que un case
porque es un case dinámico.

33
00:01:50,880 --> 00:01:54,960
De hecho, depende de la clases
cargadas y de las instancias creadas.

34
00:01:55,720 --> 00:01:58,640
En realidad, cuando programa en Java,

35
00:01:58,800 --> 00:02:02,040
a menudo escribe x.f()

36
00:02:02,200 --> 00:02:04,080
para invocar al método f.

37
00:02:04,240 --> 00:02:07,240
Lo que estoy explicando ahora es:
el punto, este,

38
00:02:08,000 --> 00:02:09,560
es un operador de elección.

39
00:02:10,840 --> 00:02:12,600
Es realmente crucial

40
00:02:13,400 --> 00:02:15,360
que esta elección es dinámica.

41
00:02:15,520 --> 00:02:17,800
A menudo no le ha sido presentado así,

42
00:02:17,960 --> 00:02:22,960
pero esto es en realidad
lo que se ejemplifica fuertemente aquí.

43
00:02:23,120 --> 00:02:25,840
En resumen, cuando envía un mensaje,

44
00:02:26,000 --> 00:02:29,360
realmente funciona
como si utilizara una sentencia case

45
00:02:29,520 --> 00:02:33,120
en el sentido de que depende
de las clases cargadas

46
00:02:33,280 --> 00:02:36,440
Este ejemplo booleano
tiene dos instancias y dos clases;

47
00:02:36,600 --> 00:02:39,600
podria tener 50,
i funcionaría de la misma manera.

48
00:02:40,320 --> 00:02:43,920
Cada vez que envíe un mensaje
a la maquina virtual

49
00:02:44,080 --> 00:02:47,400
ya que Pharo tiene una
como Java o C#

50
00:02:47,560 --> 00:02:50,520
la herramienta de ejecución de la máquina virtual

51
00:02:50,680 --> 00:02:54,400
selecciona el método correcto
dependiendo de la clase del receptor.

52
00:02:54,560 --> 00:02:58,160
Entonces enviar un mensaje
es un mecanismo de elección.

53
00:02:58,320 --> 00:03:00,520
Y cada vez que usa una condición,

54
00:03:00,680 --> 00:03:04,360
usted reemplaza este proceso

55
00:03:04,520 --> 00:03:07,920
implementado en la maquina virtual
que realiza una elección.

56
00:03:08,800 --> 00:03:11,400
Entonces las soluciones con not enseñan

57
00:03:11,560 --> 00:03:13,560
utilicemos la elección

58
00:03:13,720 --> 00:03:17,240
realizada por la máquina virtual
para implementar nuestros programas

59
00:03:17,400 --> 00:03:19,720
No necesitamos utilizar ningún if.

60
00:03:19,880 --> 00:03:24,240
porque enviar un mensaje significa
realizar un if o una condición

61
00:03:24,400 --> 00:03:26,920
La pregunta que ahora se puede hacer:

62
00:03:27,080 --> 00:03:31,160
¿Qué sucedería si hubiera expresado el primer
ejercicio de una manera totalmente diferente?

63
00:03:31,320 --> 00:03:35,160
¿Qué sucedería si hubiera dicho:"¿Puede implementar
Not en la clase booleana,

64
00:03:35,320 --> 00:03:37,000
Or en la clase booleana? "

65
00:03:37,160 --> 00:03:39,400
Esta solución no habría funcionado.

66
00:03:40,200 --> 00:03:42,720
Eso es extraño.
Qué significa eso?

67
00:03:42,880 --> 00:03:45,680
Tener una o varias clases
tiene un gran impacto

68
00:03:45,840 --> 00:03:48,400
la forma en que diseño mis aplicaciones.

69
00:03:49,120 --> 00:03:50,120
En efecto,

70
00:03:51,440 --> 00:03:56,560
las clases juegan el rol
de ramas o elecciones.

71
00:03:56,720 --> 00:03:59,080
Entonces si tiene una opción
para elegir yogur,

72
00:03:59,240 --> 00:04:03,200
pero va a una tienda que solo tiene uno,
elegirá este yogur.

73
00:04:03,360 --> 00:04:04,400
Es lo mismo.

74
00:04:04,560 --> 00:04:06,520
Significa que su clase representa

75
00:04:07,520 --> 00:04:09,440
una elección en su árbol de herencia.

76
00:04:09,600 --> 00:04:10,880
¿Qué implica?

77
00:04:11,040 --> 00:04:14,040
Esto implica que cuando miro un diseño

78
00:04:14,200 --> 00:04:17,160
con una clase muy gorda llena de métodos,

79
00:04:17,320 --> 00:04:20,920
En su lugar
podría expresarlo con una jerarquía.

80
00:04:21,080 --> 00:04:25,280
Este diseño es mejor.
porque es más modular.

81
00:04:25,440 --> 00:04:29,680
Puede fácilmente
agregar otra opción si lo desea.

82
00:04:29,840 --> 00:04:32,760
Puedo extender una elección y decir:
"Esto no fue malo.

83
00:04:32,920 --> 00:04:35,960
"Puedo refinar-lo para tener uno nuevo".

84
00:04:36,120 --> 00:04:38,880
Además, puede reducir la complejidad:

85
00:04:39,040 --> 00:04:43,840
Puedo enfocarme solo en una clase, no
en algo con tantas condiciones.

86
00:04:44,800 --> 00:04:49,000
Entonces, por un lado,
tenemos un operador de elección;

87
00:04:49,160 --> 00:04:52,640
y por otro lado,
algo que expresa elección.

88
00:04:52,800 --> 00:04:57,640
Cuando las juntas,
obtienes OOP de buena calidad.

89
00:04:57,800 --> 00:05:00,040
Lo que es mejor

90
00:05:00,200 --> 00:05:03,520
es que cuando se ve
en la solución con jerarquías,

91
00:05:03,680 --> 00:05:07,120
es aun mejor
porque puede empaquetar las soluciones.

92
00:05:07,280 --> 00:05:11,480
Significa que puedo empaquetar esto como core (cuerpo),
y este como plugin (complemento).

93
00:05:11,640 --> 00:05:14,640
Le diré a mi cliente,
"Si desea esta función,

94
00:05:14,800 --> 00:05:17,720
"solo necesita descargar este complemento
por supuesto pagándolo".

95
00:05:17,880 --> 00:05:20,360
Cargaré este código dinámicamente.

96
00:05:20,520 --> 00:05:23,760
Cuando cree una instancia de esta clase,

97
00:05:25,400 --> 00:05:27,840
cuando envíe mi mensaje operation aquí,

98
00:05:28,520 --> 00:05:31,840
será el código del complemento que
se ejecutara en el sistema.

99
00:05:32,000 --> 00:05:36,440
Para nosotros, esa es la esencia de OOP.

100
00:05:36,600 --> 00:05:40,120
Envío un mensaje
y seleccionare el método correcto.

101
00:05:40,960 --> 00:05:45,040
Y usaré el hecho de que conozco
que el sistema selecciona el método correcto

102
00:05:45,200 --> 00:05:47,960
para ser aún más elegante
en mis implementaciones

103
00:05:48,120 --> 00:05:50,320
¿Qué hemos aprendido?

104
00:05:50,480 --> 00:05:55,040
Hemos aprendido que enviar un mensaje
permite que el receptor decida y elija.

105
00:05:55,200 --> 00:05:58,400
El cliente no tiene que decidir.

106
00:05:58,560 --> 00:06:00,760
El código del cliente es más declarativo.

107
00:06:00,920 --> 00:06:04,800
No hay condiciones Doy órdenes:
haz esto, hazlo, abre, cierra;

108
00:06:04,960 --> 00:06:09,280
¿Perteneces a esta clase?
¿Estás listo para estar cerrado?

109
00:06:09,440 --> 00:06:12,520
Diferentes receptores
puede ser sustituidos dinámicamente.

110
00:06:12,680 --> 00:06:15,840
Veremos más adelante esto,
pero está implícito

111
00:06:16,560 --> 00:06:20,240
Así que la mayoría de las veces,
Intente evitar escribir ifs.

112
00:06:21,240 --> 00:06:23,560
Use objetos y mensajes cuando pueda.

113
00:06:23,720 --> 00:06:27,760
No siempre es el caso,
pero úselas al menos cuando pueda.

114
00:06:29,280 --> 00:06:31,880
El motor de ejecución,
la maquina virtual,

115
00:06:32,040 --> 00:06:37,120
actúa como un distribuidor condicional
cada vez que envíe un mensaje

116
00:06:37,680 --> 00:06:39,000
Entonces utilícelo.

117
00:06:39,160 --> 00:06:41,960
También puede divertirse
escribiendo el AntiIfCampaign.

118
00:06:42,120 --> 00:06:46,800
Los programadores lanzaron esta campaña
para conseguir que la gente deje de escribir ifs.

119
00:06:48,760 --> 00:06:50,960
Entonces, ¿qué hemos aprendido en esta sesión?

120
00:06:51,120 --> 00:06:53,280
Dos cosas: cuando escribo x.f(),

121
00:06:53,440 --> 00:06:57,720
ya sea en Java o en Pharo,

122
00:06:58,600 --> 00:07:02,400
Realizo una elección:
Elijo el método f

123
00:07:02,560 --> 00:07:06,080
que debe ejecutarse
dependiendo del receptor.

124
00:07:06,840 --> 00:07:08,640
Entonces tengo este
 operador de elección

125
00:07:08,800 --> 00:07:12,000
y una jerarquía
que representa diferentes elecciones potenciales.

126
00:07:12,160 --> 00:07:16,560
Entonces, realmente es un esqueleto.
en el que la elección se puede apoyar.

127
00:07:16,720 --> 00:07:20,800
De golpe, no tengo condicionales.
y programas más extensibles.

128
00:07:21,800 --> 00:07:24,480
Este es el final de la primera sesión

129
00:07:24,640 --> 00:07:27,160
sobre diseño de objetos en Pharo.

130
00:07:28,160 --> 00:07:30,520
Y veremos más
en las próximas sesiones.