WEBVTT

00:00:00.440 --> 00:00:02.600 align:middle
Hola. En la sesión anterior,

00:00:02.760 --> 00:00:06.880 align:middle
vimos cómo implementar
los booleanos: not y or

00:00:07.040 --> 00:00:11.960 align:middle
Estaba pendiente la tercera pregunta:
¿Por qué diablos hicimos estas preguntas?

00:00:12.120 --> 00:00:13.880 align:middle
Eso es lo que vamos a estudiar.

00:00:14.760 --> 00:00:20.120 align:middle
Repasemos la implementación.
Para not, había dos objetos.

00:00:20.280 --> 00:00:22.400 align:middle
Teníamos true y false.

00:00:22.560 --> 00:00:25.440 align:middle
Eran instancias
de las clases True y False.

00:00:25.600 --> 00:00:27.200 align:middle
Cuando enviamos un mensaje not,

00:00:27.360 --> 00:00:31.640 align:middle
preguntamos a sus respectivas clases
y ejecutamos los métodos.

00:00:32.560 --> 00:00:34.080 align:middle
Entonces, no tenemos problema aquí.

00:00:35.120 --> 00:00:37.240 align:middle
Como ya he dicho,

00:00:37.400 --> 00:00:39.720 align:middle
si mira lo que está haciendo:

00:00:39.880 --> 00:00:42.920 align:middle
Primero, deja que el receptor decida.

00:00:43.080 --> 00:00:46.080 align:middle
Significa que no toma ninguna decisión,

00:00:46.240 --> 00:00:49.320 align:middle
usted envía un mensaje
que se resolverá por sí mismo.

00:00:49.480 --> 00:00:53.840 align:middle
Entonces, estas dos funciones heurísticas eran:
deje que decida el receptor;

00:00:54.000 --> 00:00:57.320 align:middle
y no pregunte sino diga que hacer.

00:00:57.480 --> 00:00:58.960 align:middle
Voy a mencionar esto nuevamente.

00:00:59.120 --> 00:01:02.480 align:middle
Ahora echemos un vistazo al ejercicio en sí.

00:01:03.080 --> 00:01:04.720 align:middle
Entonces, ¿que es lo que ilustra?

00:01:04.880 --> 00:01:08.240 align:middle
Nunca implementara booleanos.
en su vida,

00:01:08.400 --> 00:01:10.080 align:middle
por lo menos eso espero.

00:01:10.240 --> 00:01:13.000 align:middle
¿Es realmente inútil?

00:01:13.160 --> 00:01:15.920 align:middle
¿Cuáles son las lecciones subyacentes?

00:01:16.080 --> 00:01:19.240 align:middle
Creo que es muy importante
de hacerse esta pregunta:

00:01:19.400 --> 00:01:23.600 align:middle
Sí, la implementación es así,
pero, ¿que ilustra?

00:01:24.560 --> 00:01:29.360 align:middle
De hecho, se ve
que cada vez que envío un mensaje,

00:01:29.520 --> 00:01:33.640 align:middle
cada vez que envío un mensaje,
Tengo algún tipo de sentencia case.

00:01:35.000 --> 00:01:38.800 align:middle
Que encontrará
en programación C, etc.

00:01:39.880 --> 00:01:42.840 align:middle
Enviando un mensaje
Realiza una elección múltiple.

00:01:44.160 --> 00:01:46.880 align:middle
Lo que es interesante es:
cuando envía un mensaje,

00:01:47.040 --> 00:01:50.720 align:middle
al final, es más que un case
porque es un case dinámico.

00:01:50.880 --> 00:01:54.960 align:middle
De hecho, depende de la clases
cargadas y de las instancias creadas.

00:01:55.720 --> 00:01:58.640 align:middle
En realidad, cuando programa en Java,

00:01:58.800 --> 00:02:02.040 align:middle
a menudo escribe x.f()

00:02:02.200 --> 00:02:04.080 align:middle
para invocar al método f.

00:02:04.240 --> 00:02:07.240 align:middle
Lo que estoy explicando ahora es:
el punto, este,

00:02:08.000 --> 00:02:09.560 align:middle
es un operador de elección.

00:02:10.840 --> 00:02:12.600 align:middle
Es realmente crucial

00:02:13.400 --> 00:02:15.360 align:middle
que esta elección es dinámica.

00:02:15.520 --> 00:02:17.800 align:middle
A menudo no le ha sido presentado así,

00:02:17.960 --> 00:02:22.960 align:middle
pero esto es en realidad
lo que se ejemplifica fuertemente aquí.

00:02:23.120 --> 00:02:25.840 align:middle
En resumen, cuando envía un mensaje,

00:02:26.000 --> 00:02:29.360 align:middle
realmente funciona
como si utilizara una sentencia case

00:02:29.520 --> 00:02:33.120 align:middle
en el sentido de que depende
de las clases cargadas

00:02:33.280 --> 00:02:36.440 align:middle
Este ejemplo booleano
tiene dos instancias y dos clases;

00:02:36.600 --> 00:02:39.600 align:middle
podria tener 50,
i funcionaría de la misma manera.

00:02:40.320 --> 00:02:43.920 align:middle
Cada vez que envíe un mensaje
a la maquina virtual

00:02:44.080 --> 00:02:47.400 align:middle
ya que Pharo tiene una
como Java o C#

00:02:47.560 --> 00:02:50.520 align:middle
la herramienta de ejecución de la máquina virtual

00:02:50.680 --> 00:02:54.400 align:middle
selecciona el método correcto
dependiendo de la clase del receptor.

00:02:54.560 --> 00:02:58.160 align:middle
Entonces enviar un mensaje
es un mecanismo de elección.

00:02:58.320 --> 00:03:00.520 align:middle
Y cada vez que usa una condición,

00:03:00.680 --> 00:03:04.360 align:middle
usted reemplaza este proceso

00:03:04.520 --> 00:03:07.920 align:middle
implementado en la maquina virtual
que realiza una elección.

00:03:08.800 --> 00:03:11.400 align:middle
Entonces las soluciones con not enseñan

00:03:11.560 --> 00:03:13.560 align:middle
utilicemos la elección

00:03:13.720 --> 00:03:17.240 align:middle
realizada por la máquina virtual
para implementar nuestros programas

00:03:17.400 --> 00:03:19.720 align:middle
No necesitamos utilizar ningún if.

00:03:19.880 --> 00:03:24.240 align:middle
porque enviar un mensaje significa
realizar un if o una condición

00:03:24.400 --> 00:03:26.920 align:middle
La pregunta que ahora se puede hacer:

00:03:27.080 --> 00:03:31.160 align:middle
¿Qué sucedería si hubiera expresado el primer
ejercicio de una manera totalmente diferente?

00:03:31.320 --> 00:03:35.160 align:middle
¿Qué sucedería si hubiera dicho:"¿Puede implementar
Not en la clase booleana,

00:03:35.320 --> 00:03:37.000 align:middle
Or en la clase booleana? "

00:03:37.160 --> 00:03:39.400 align:middle
Esta solución no habría funcionado.

00:03:40.200 --> 00:03:42.720 align:middle
Eso es extraño.
Qué significa eso?

00:03:42.880 --> 00:03:45.680 align:middle
Tener una o varias clases
tiene un gran impacto

00:03:45.840 --> 00:03:48.400 align:middle
la forma en que diseño mis aplicaciones.

00:03:49.120 --> 00:03:50.120 align:middle
En efecto,

00:03:51.440 --> 00:03:56.560 align:middle
las clases juegan el rol
de ramas o elecciones.

00:03:56.720 --> 00:03:59.080 align:middle
Entonces si tiene una opción
para elegir yogur,

00:03:59.240 --> 00:04:03.200 align:middle
pero va a una tienda que solo tiene uno,
elegirá este yogur.

00:04:03.360 --> 00:04:04.400 align:middle
Es lo mismo.

00:04:04.560 --> 00:04:06.520 align:middle
Significa que su clase representa

00:04:07.520 --> 00:04:09.440 align:middle
una elección en su árbol de herencia.

00:04:09.600 --> 00:04:10.880 align:middle
¿Qué implica?

00:04:11.040 --> 00:04:14.040 align:middle
Esto implica que cuando miro un diseño

00:04:14.200 --> 00:04:17.160 align:middle
con una clase muy gorda llena de métodos,

00:04:17.320 --> 00:04:20.920 align:middle
En su lugar
podría expresarlo con una jerarquía.

00:04:21.080 --> 00:04:25.280 align:middle
Este diseño es mejor.
porque es más modular.

00:04:25.440 --> 00:04:29.680 align:middle
Puede fácilmente
agregar otra opción si lo desea.

00:04:29.840 --> 00:04:32.760 align:middle
Puedo extender una elección y decir:
"Esto no fue malo.

00:04:32.920 --> 00:04:35.960 align:middle
"Puedo refinar-lo para tener uno nuevo".

00:04:36.120 --> 00:04:38.880 align:middle
Además, puede reducir la complejidad:

00:04:39.040 --> 00:04:43.840 align:middle
Puedo enfocarme solo en una clase, no
en algo con tantas condiciones.

00:04:44.800 --> 00:04:49.000 align:middle
Entonces, por un lado,
tenemos un operador de elección;

00:04:49.160 --> 00:04:52.640 align:middle
y por otro lado,
algo que expresa elección.

00:04:52.800 --> 00:04:57.640 align:middle
Cuando las juntas,
obtienes OOP de buena calidad.

00:04:57.800 --> 00:05:00.040 align:middle
Lo que es mejor

00:05:00.200 --> 00:05:03.520 align:middle
es que cuando se ve
en la solución con jerarquías,

00:05:03.680 --> 00:05:07.120 align:middle
es aun mejor
porque puede empaquetar las soluciones.

00:05:07.280 --> 00:05:11.480 align:middle
Significa que puedo empaquetar esto como core (cuerpo),
y este como plugin (complemento).

00:05:11.640 --> 00:05:14.640 align:middle
Le diré a mi cliente,
"Si desea esta función,

00:05:14.800 --> 00:05:17.720 align:middle
"solo necesita descargar este complemento
por supuesto pagándolo".

00:05:17.880 --> 00:05:20.360 align:middle
Cargaré este código dinámicamente.

00:05:20.520 --> 00:05:23.760 align:middle
Cuando cree una instancia de esta clase,

00:05:25.400 --> 00:05:27.840 align:middle
cuando envíe mi mensaje operation aquí,

00:05:28.520 --> 00:05:31.840 align:middle
será el código del complemento que
se ejecutara en el sistema.

00:05:32.000 --> 00:05:36.440 align:middle
Para nosotros, esa es la esencia de OOP.

00:05:36.600 --> 00:05:40.120 align:middle
Envío un mensaje
y seleccionare el método correcto.

00:05:40.960 --> 00:05:45.040 align:middle
Y usaré el hecho de que conozco
que el sistema selecciona el método correcto

00:05:45.200 --> 00:05:47.960 align:middle
para ser aún más elegante
en mis implementaciones

00:05:48.120 --> 00:05:50.320 align:middle
¿Qué hemos aprendido?

00:05:50.480 --> 00:05:55.040 align:middle
Hemos aprendido que enviar un mensaje
permite que el receptor decida y elija.

00:05:55.200 --> 00:05:58.400 align:middle
El cliente no tiene que decidir.

00:05:58.560 --> 00:06:00.760 align:middle
El código del cliente es más declarativo.

00:06:00.920 --> 00:06:04.800 align:middle
No hay condiciones Doy órdenes:
haz esto, hazlo, abre, cierra;

00:06:04.960 --> 00:06:09.280 align:middle
¿Perteneces a esta clase?
¿Estás listo para estar cerrado?

00:06:09.440 --> 00:06:12.520 align:middle
Diferentes receptores
puede ser sustituidos dinámicamente.

00:06:12.680 --> 00:06:15.840 align:middle
Veremos más adelante esto,
pero está implícito

00:06:16.560 --> 00:06:20.240 align:middle
Así que la mayoría de las veces,
Intente evitar escribir ifs.

00:06:21.240 --> 00:06:23.560 align:middle
Use objetos y mensajes cuando pueda.

00:06:23.720 --> 00:06:27.760 align:middle
No siempre es el caso,
pero úselas al menos cuando pueda.

00:06:29.280 --> 00:06:31.880 align:middle
El motor de ejecución,
la maquina virtual,

00:06:32.040 --> 00:06:37.120 align:middle
actúa como un distribuidor condicional
cada vez que envíe un mensaje

00:06:37.680 --> 00:06:39.000 align:middle
Entonces utilícelo.

00:06:39.160 --> 00:06:41.960 align:middle
También puede divertirse
escribiendo el AntiIfCampaign.

00:06:42.120 --> 00:06:46.800 align:middle
Los programadores lanzaron esta campaña
para conseguir que la gente deje de escribir ifs.

00:06:48.760 --> 00:06:50.960 align:middle
Entonces, ¿qué hemos aprendido en esta sesión?

00:06:51.120 --> 00:06:53.280 align:middle
Dos cosas: cuando escribo x.f(),

00:06:53.440 --> 00:06:57.720 align:middle
ya sea en Java o en Pharo,

00:06:58.600 --> 00:07:02.400 align:middle
Realizo una elección:
Elijo el método f

00:07:02.560 --> 00:07:06.080 align:middle
que debe ejecutarse
dependiendo del receptor.

00:07:06.840 --> 00:07:08.640 align:middle
Entonces tengo este
 operador de elección

00:07:08.800 --> 00:07:12.000 align:middle
y una jerarquía
que representa diferentes elecciones potenciales.

00:07:12.160 --> 00:07:16.560 align:middle
Entonces, realmente es un esqueleto.
en el que la elección se puede apoyar.

00:07:16.720 --> 00:07:20.800 align:middle
De golpe, no tengo condicionales.
y programas más extensibles.

00:07:21.800 --> 00:07:24.480 align:middle
Este es el final de la primera sesión

00:07:24.640 --> 00:07:27.160 align:middle
sobre diseño de objetos en Pharo.

00:07:28.160 --> 00:07:30.520 align:middle
Y veremos más
en las próximas sesiones.