Hola. En la sesión anterior,
vimos cómo implementar los booleanos: not y or
Estaba pendiente la tercera pregunta: ¿Por qué diablos hicimos estas preguntas?
Eso es lo que vamos a estudiar.
Repasemos la implementación. Para not, había dos objetos.
Teníamos true y false.
Eran instancias de las clases True y False.
Cuando enviamos un mensaje not,
preguntamos a sus respectivas clases y ejecutamos los métodos.
Entonces, no tenemos problema aquí.
Como ya he dicho,
si mira lo que está haciendo:
Primero, deja que el receptor decida.
Significa que no toma ninguna decisión,
usted envía un mensaje que se resolverá por sí mismo.
Entonces, estas dos funciones heurísticas eran: deje que decida el receptor;
y no pregunte sino diga que hacer.
Voy a mencionar esto nuevamente.
Ahora echemos un vistazo al ejercicio en sí.
Entonces, ¿que es lo que ilustra?
Nunca implementara booleanos. en su vida,
por lo menos eso espero.
¿Es realmente inútil?
¿Cuáles son las lecciones subyacentes?
Creo que es muy importante de hacerse esta pregunta:
Sí, la implementación es así, pero, ¿que ilustra?
De hecho, se ve que cada vez que envío un mensaje,
cada vez que envío un mensaje, Tengo algún tipo de sentencia case.
Que encontrará en programación C, etc.
Enviando un mensaje Realiza una elección múltiple.
Lo que es interesante es: cuando envía un mensaje,
al final, es más que un case porque es un case dinámico.
De hecho, depende de la clases cargadas y de las instancias creadas.
En realidad, cuando programa en Java,
a menudo escribe x.f()
para invocar al método f.
Lo que estoy explicando ahora es: el punto, este,
es un operador de elección.
Es realmente crucial
que esta elección es dinámica.
A menudo no le ha sido presentado así,
pero esto es en realidad lo que se ejemplifica fuertemente aquí.
En resumen, cuando envía un mensaje,
realmente funciona como si utilizara una sentencia case
en el sentido de que depende de las clases cargadas
Este ejemplo booleano tiene dos instancias y dos clases;
podria tener 50, i funcionaría de la misma manera.
Cada vez que envíe un mensaje a la maquina virtual
ya que Pharo tiene una como Java o C#
la herramienta de ejecución de la máquina virtual
selecciona el método correcto dependiendo de la clase del receptor.
Entonces enviar un mensaje es un mecanismo de elección.
Y cada vez que usa una condición,
usted reemplaza este proceso
implementado en la maquina virtual que realiza una elección.
Entonces las soluciones con not enseñan
utilicemos la elección
realizada por la máquina virtual para implementar nuestros programas
No necesitamos utilizar ningún if.
porque enviar un mensaje significa realizar un if o una condición
La pregunta que ahora se puede hacer:
¿Qué sucedería si hubiera expresado el primer ejercicio de una manera totalmente diferente?
¿Qué sucedería si hubiera dicho:"¿Puede implementar Not en la clase booleana,
Or en la clase booleana? "
Esta solución no habría funcionado.
Eso es extraño. Qué significa eso?
Tener una o varias clases tiene un gran impacto
la forma en que diseño mis aplicaciones.
En efecto,
las clases juegan el rol de ramas o elecciones.
Entonces si tiene una opción para elegir yogur,
pero va a una tienda que solo tiene uno, elegirá este yogur.
Es lo mismo.
Significa que su clase representa
una elección en su árbol de herencia.
¿Qué implica?
Esto implica que cuando miro un diseño
con una clase muy gorda llena de métodos,
En su lugar podría expresarlo con una jerarquía.
Este diseño es mejor. porque es más modular.
Puede fácilmente agregar otra opción si lo desea.
Puedo extender una elección y decir: "Esto no fue malo.
"Puedo refinar-lo para tener uno nuevo".
Además, puede reducir la complejidad:
Puedo enfocarme solo en una clase, no en algo con tantas condiciones.
Entonces, por un lado, tenemos un operador de elección;
y por otro lado, algo que expresa elección.
Cuando las juntas, obtienes OOP de buena calidad.
Lo que es mejor
es que cuando se ve en la solución con jerarquías,
es aun mejor porque puede empaquetar las soluciones.
Significa que puedo empaquetar esto como core (cuerpo), y este como plugin (complemento).
Le diré a mi cliente, "Si desea esta función,
"solo necesita descargar este complemento por supuesto pagándolo".
Cargaré este código dinámicamente.
Cuando cree una instancia de esta clase,
cuando envíe mi mensaje operation aquí,
será el código del complemento que se ejecutara en el sistema.
Para nosotros, esa es la esencia de OOP.
Envío un mensaje y seleccionare el método correcto.
Y usaré el hecho de que conozco que el sistema selecciona el método correcto
para ser aún más elegante en mis implementaciones
¿Qué hemos aprendido?
Hemos aprendido que enviar un mensaje permite que el receptor decida y elija.
El cliente no tiene que decidir.
El código del cliente es más declarativo.
No hay condiciones Doy órdenes: haz esto, hazlo, abre, cierra;
¿Perteneces a esta clase? ¿Estás listo para estar cerrado?
Diferentes receptores puede ser sustituidos dinámicamente.
Veremos más adelante esto, pero está implícito
Así que la mayoría de las veces, Intente evitar escribir ifs.
Use objetos y mensajes cuando pueda.
No siempre es el caso, pero úselas al menos cuando pueda.
El motor de ejecución, la maquina virtual,
actúa como un distribuidor condicional cada vez que envíe un mensaje
Entonces utilícelo.
También puede divertirse escribiendo el AntiIfCampaign.
Los programadores lanzaron esta campaña para conseguir que la gente deje de escribir ifs.
Entonces, ¿qué hemos aprendido en esta sesión?
Dos cosas: cuando escribo x.f(),
ya sea en Java o en Pharo,
Realizo una elección: Elijo el método f
que debe ejecutarse dependiendo del receptor.
Entonces tengo este operador de elección
y una jerarquía que representa diferentes elecciones potenciales.
Entonces, realmente es un esqueleto. en el que la elección se puede apoyar.
De golpe, no tengo condicionales. y programas más extensibles.
Este es el final de la primera sesión
sobre diseño de objetos en Pharo.
Y veremos más en las próximas sesiones.