Polimorfismo

Esta es la metodología que vamos a usar para resolver los ejercicios en toda la cursada:

1. ¿Cuál es el requerimiento? (uno, el primero, o el siguiente si ya hay algo resuelto)
   • Focalizamos en una parte del problema: "dividir y conquistar"
   • Respuesta: Calcular el sueldo base de pepe
2. ¿Qué mensaje vamos a enviar a qué objeto (y con qué parámetros)?
   • Pensamos primero en cómo vamos a usar los objetos (pensar en el mensaje antes que en el método)
   • Armar una lista de objetos candidatos, si es necesario
   • Acá puede salir varias posibilidades, está bueno anotarlas todas para después definir
   • Respuesta: pepe.cambiarCategoria(gerente)
3. Escribimos un ejemplo concreto del mensaje
   • Lo escribimos en la consola. Sí, ¡antes de escribir el código!
   • Vemos que todo rompe porque no está implementado, pero ¡no nos asustamos!
4. Acción o consulta
   • Este es ¿un mensaje de acción o de consulta?
     • Si es acción, ¿qué esperamos que pase?
     • Si es conuslta, ¿qué esperamos que devuelva?
   • Respuesta: Es de acción, Pepe debe cambiar su categoría de cadete a gerente.
5. Implementación
   • Codear lo necesario para que el ejemplo se comporte como esperamos
   • Pensar si hay más ejemplos para tener en cuenta
     • Implementar lo necesario para el nuevo ejemplo si es necesario
6. Repetir hasta terminar el ejercicio - Iterar

Proponemos esta metodología porque:

• Focaliza en una parte del problema (y por el momento nos olvidamos del resto)
• Primero piensa en el qué antes que en el cómo
  • O sea, primero pensamos en mensaje antes que en la implementación del método
• Propone un objetivo claro
  • Al escribir el uso en la consola, ya tenemos en claro qué le falta al sistema
  • Le perdemos el miedo a que nos explote un programa en la cara (práctica de debugging)
  • El requerimiento se resuelve cuando la consola deje de fallarnos (los errores guían el desarrollo)
• En fin, propone una forma de trabajar iterativa e incremental

Como el paradigma de objetos propone tener objetos encapsulados, o sea, cada uno maneja su estado interno (atributos), los métodos que solo cambian o retornan algún atributo son muy comunes en los programas.

Vamos a jugar un poco con el código:

1. Abrimos una nueva sesión de la consola
2. Cerramos el diagrama dinámico (en realidad conviene solo ocultarlo, para poder verlo rápido durante la explicación)
3. Y le cambiamos la categoría a Pepe

pepe> pepe.cambiarCategoria(gerente)
✓ 

Preguntas gatillo

Si no vemos el diagrama ¿cómo sabemos que Pepe cambió de su categoría?

Respuesta: hay que mandarle un mensaje preguntándole su categoría: pepe.obtenerCategoria()

¿Ese es un mensaje de acción o consulta?

Respuesta: consulta. Debe retornar su categoría, o sea, el objeto apuntado por su atributo

Acá podemos mostrar el diagrama rápidamente para entender que queremos retornar el objeto apuntado (y no un string u otra cosa que lo represente).

También podemos evaluar directamente esos objetos para que se entienda:

pepe> cadete
✓ cadete
pepe> gerente
✓ gerente

Pero si lo consultamos ahora nos da un error diciendo que no entiende el mensaje:

pepe> pepe.obtenerCategoria()
✗ Evaluation Error!
  wollok.lang.MessageNotUnderstoodException: pepe does not understand obtenerCategoria()

Repasamos cómo seguir a partir de acá:

• No entiende el mensaje porque no implementa un método
• Hay que definir un método en el objeto pepe que se llame obtenerCategoria/0
• Ese método debe retornar el atributo categoria

Lo escribimos (acá solo se presenta el código de pepe, el resto queda igual)

object pepe { 

    var categoria = cadete

    method cambiarCategoria(unaCategoria) {
        categoria = unaCategoria
    }

    method obtenerCategoria() = categoria

}

(podría ser su versión con ( return ... ))

Y reevaluamos todo con :rr y vemos que ya no explota nada.

Ahora podemos intercalar los cambiar y obtener (podemos limpiar la consola con ctrl + k o ctrl + l o algo similar):

pepe> pepe.cambiarCategoria(cadete)
✓ 
pepe> pepe.obtenerCategoria()
✓ cadete
pepe> pepe.cambiarCategoria(gerente)
✓ 
pepe> pepe.obtenerCategoria()
✓ gerente

Acá explicamos cómo se conocen (por sus nombres en inglés) estos métodos:

• El método que cambia un atributo por un parámetro se conocen como setter: cambiarCategoria/1, cambiarEnergia/1, cambiarAlgo/1
• El método que retorna un atributo (y no tiene parámetros) se conocen como getter: obtenerCategoria/0, obtenerEnergia/0, obtenerAlgo/0
• Los lenguajes de programación (y su comunidad) generalmente definen una forma para el nombre de estos métodos
  • por ej: setCategoria/1 y getCategoria/0
  • esto se conoce como convención: una forma de nombrar algún elemento del programa en el que se ponen de acuerdo la comunidad

La convención de Wollok para los getters y setters es con el mismo nombre del atributo (sin prefijo): categoria/1 y categoria/0

Modificamos el código:

object pepe { 

    var categoria = cadete

    method categoria(unaCategoria) {
        categoria = unaCategoria
    }

    method categoria() = categoria

}

Levantamos una nueva consola y volvemos a hacer las consultas con los nuevos nombres:

pepe> pepe.categoria(gerente)
✓ 
pepe> pepe.categoria()
✓ gerente
pepe> pepe.categoria(cadete)
✓ 
pepe> pepe.categoria()
✓ cadete

Atención

Resaltar que ahora en el código de pepe hay 3 cosas distintas que se llaman "categoria":

1. Definición del atributo: var categoria
2. Método setter: method categoria(unaCategoria)
3. Método getter: method categoria()

• Los atributos y métodos se definen y usan de forma distintas
  • Los atributos se definen con var o const, mientras que los métodos con method
  • Los atributos se usan como cualquier referencia, mientras que los métodos a través de envios de mensajes (después de un .)
• Los getter y setter tienen distinta firma, debido a sus parámetros
  • Los getters no esperan parámetro y son de consulta: categoria/0
  • Los setters esperan el nuevo objeto y son de acción: categoria/1
  • Como tienen distintos parámetros, se invoca uno u otro método en base a los parámetros que tiene el mensaje

Como estos métodos son comunes en los lenguajes orientado a objetos, muchos traen una forma de declararlos fácilmente.

En Wollok, se puede usar el modificador property en la definición de un atributo para crear sus getters y setters.

El código de pepe quedaría así (dejo la versión con comentarios para los estudiantes, pero se sugiere probarlo sin los métodos escritos para que se entienda cómo funciona):

object pepe { 

    var property categoria = "asd."

/*
Este código se crea con el "property" del atributo categoria

Está comentado para recordar lo que hace, pero no hace falta escribirlos

GETTER:
    method categoria(unaCategoria) {
        categoria = unaCategoria
    }

SETTER:
    method categoria() = categoria
*/
}

Y repetimos las consultas para probar que anda (probar es siempre mucho muy importante):

pepe> :rr
✓ Reloading environment
pepe> pepe.categoria(gerente)
✓ 
pepe> pepe.categoria()
✓ gerente
pepe> pepe.categoria(cadete)
✓ 
pepe> pepe.categoria()
✓ cadete

• var property vs const property
• ¿Qué pasa si escribo un método getter o setter usando property?
• Ahora tengo un getter y antes no, ¿es eso mejor?

Preguntas gatillo

¿Ya terminamos?

Respuesta: no. Todavía falta probar siendo gerente.

Pensar todos los casos de prueba es algo importante que queremos ejercitar y lo vamos a estar practicando la clase que viene

¿Y cómo probamos ese caso?

Respuesta: hay que cambiarle la categoria a gerente y preguntarle el sueldo base

pepe> pepe.categoria(gerente)
✓ 
pepe> pepe.sueldoBase()
✗ Evaluation Error!
  wollok.lang.MessageNotUnderstoodException: gerente does not understand extra()
    at pepe.pepe.sueldoBase() [pepe.wlk:5]

Nos dice que gerente no entiende el mensaje extra(). ¡Que bueno! que probamos este caso, nos falta implementar parte del código aún.

Implementamos el método que falta:

object gerente { 
    method extra() = 1500
}

Y volvemos a probar todo

pepe> :rr
✓ Reloading environment
pepe> pepe.sueldoBase()
✓ 1500
pepe> pepe.categoria(gerente)
✓ 
pepe> pepe.sueldoBase()
✓ 2500

¡Genial! Ahora sí ya terminamos

Es una referencia que conocen todos los objetos y que apunta a sí mismos

Cambiar el código para arreglar el aviso y probar que la consola se sigue comportando igual

method sueldo() = self.sueldoBase()

En el diagrama dinámico, las referencias a self no aparecen, pero podemos forzarlas definiendo un atributo (yoMismo) inicializado en self en todos los objetos

object pepe { 
    const yoMismo = self

    var property categoria = cadete

    method sueldo() = self.sueldoBase()

    method sueldoBase() = 1000 + categoria.extra()

}

object cadete { 
    const yoMismo = self

    method extra() = 500
}

object gerente { 
    const yoMismo = self

    method extra() = 1500
}

Acá se visualiza:

• El "rulo" que significa una referencia a "sí mismo"
• En un programa prueden existir muchos atributos con el mismo nombre, siempre que salgan de objetos distintos
• En el código, la paralabra self significa algo distinto depende en qué objeto esté escrito

Comentar (o borrar) los atributos yoMismo para seguir con el ejercicio

Algunas aristas que puede tomar esta clase y tocan conceptos importantes

Repetir código

Este punto se puede solucionar sin self copy-pasteando la definición de sueldoBase()

method sueldo() = 1000 + categoria.extra()

method sueldoBase() = 1000 + categoria.extra()

Vamos a evitar repetir lógica a toda costa, y fomentar soluciones con reutilización de lógica

Si ya existe un componente (método) que resuelve parte de mi problema, lo mejor es aprovecharlo

Romper el requerimiento anterior

También se podría renombrar el método anterior para que se llame sueldo() y continuar desde ahí (de esa forma se evita el código repetido)

method sueldo() = 1000 + categoria.extra()

Hacer notar que esto rompe con el requierimiento anterior, y que además es contraproducente: perdemos una abstracción que ya existe

Romper la sintaxis

Un error común al comenzar la POO es olvidarse el receptor de un mensaje

method sueldo() = sueldoBase()

method sueldoBase() = 1000 + categoria.extra()

Esto marca un error en el IDE

Aún así es bueno recordar que en este paradigma (puro), todas las computaciones suceden a partir de enviar un mensaje.

Un mensaje siempre tiene (necesita de) un objeto receptor: objeto.mensaje()

Acá buscamos introducir a los distintos contratos de forma similar a las categorías

• Entender que Pepe debe estar asociado a una de los contratos: básico, porcentual o presentismo
• Se debe poder elegir (configurar) qué contrato tiene Pepe
• El sueldo se debe calcular a partir del contrato (y categoría) configurado(a)

Para eso

1. Definimos 3 nuevos objetos

object basico {

}

object porcentual {
    
}

object presentismo {
    
}

1. Agregamos un nuevo atributo en pepe

var property contrato = basico

1. Le mandamos un mensaje al contrato para calcular el sueldo

method sueldo() = self.sueldoBase() + contrato.remuneracion()

Probamos qué onda

pepe> :rr
✓ Reloading environment
> pepe.sueldo()
✗ Evaluation Error!
  wollok.lang.MessageNotUnderstoodException: basico does not understand remuneracion()
    at pepe.pepe.sueldo() [pepe.wlk:5]

Y leemos el error

basico no entiende el mensaje remuneracion()

¿Es de acción o de consulta?

Respuesta: de consulta

Implementamos el método con el código necesario para que la prueba funcione como antes

object basico {
    method remuneracion() = 1000
}

Y probamos

pepe> :rr
✓ Reloading environment
> pepe.sueldo()
2500

Al repetir estos pasos buscamos

• que se adopte la metodología de trabajo
• fortalecer el diseño que aprovecha el polimorfismo
• mostrar cómo el programa crece de forma iterativa e incremental

Una vez implementado el contrato más fácil, continuamos con el siguiente: porcentual

Este punto plantea el problema de cómo el porcentual conoce a pepe

El objetivo es introducir las 3 formas de conocer un objeto desde otro:

• global: la referencia está hardcodeada en el código
• atributo: la referencia está en un atributo del objeto
• paramétrico: la referencia viene por parámetro

Comenzamos a implementar el método

Global

La primera forma de implementar este punto suele ser la global

object porcentual {
    const porcentaje = 15
    method remuneracion() = pepe.sueldoBase() * porcentaje / 100
}

Probamos, configurando a pepe antes

pepe> pepe.contrato(porcentual)
✓ 
pepe> pepe.sueldo()
✓ 1725

Joya!

Además vemos cómo queda el diagrama

Marcamos algunas características de esta solución:

• La referencia está hardcodeada en el código del método, lo que significa que no se puede cambiar sin reestructurar el código
• Eso genera una dependencia implícita de un objeto a otro: no hay flecha en el diagrama (de porcentual hacia pepe) ni en la firma del método
• Recordamos que las referencias son "flechas direccionadas" que tienen un sentido (desde el objeto que la tiene hacia el que apunta)

Atributo

Si la referencia a pepe hardcodeada en el método molesta, entonces agreguemos otro atributo en porcentual

object porcentual {
    const porcentaje = 15
    const empleado = pepe

    method remuneracion() = empleado.sueldoBase() * porcentaje / 100
}

Así la dependencia queda evidente en el diagrama

Y todo sigue funcionando como esperábamos

pepe> pepe.contrato(porcentual)
✓ 
pepe> pepe.sueldo()
✓ 1725

Características de esta solución:

• La referencia de porcentual hacia pepe es explícita y tiene un nombre: empleado 👍
• Si bien ahora es un atributo constante, podríamos cambiar el programa para que sea variable y apunte a otro posible empleado
• Este modelo propone un par de referencias circulares entre contrato y empleado. Esto no es un problema per se, pero hay que tener cuidado: armar y romper estos vínculos implican cambiar dos referencias, con una no basta (podría dejar el un estado inconsistente)

Parámetro

Como última solución (y con la que nos vamos a quedar para este ejercicio) es pasar al empleado por parámetro:

object porcentual {
    const porcentaje = 15

    method remuneracion(empleado) = empleado.sueldoBase() * porcentaje / 100
}

A diferencia de las otras dos opciones, esta variante cambia la firma del mensaje que pepe debe mandarle a su contrato

wollok:pepe> :rr
✓ Reloading environment
wollok:pepe> pepe.contrato(porcentual)
✓ 
wollok:pepe> pepe.sueldo()
✗ Evaluation Error!
  wollok.lang.MessageNotUnderstoodException: porcentual does not understand remuneracion()
    at pepe.pepe.sueldo() [pepe.wlk:5]

remuneracion() sin parámetros y remuneracion(empleado) con parámetro tienen distinta firma, o sea que responden a mensajes distintos. Uno es remuneracion/0 y el otro remuneracion/1

Ajustamos el mensaje en el método sueldo():

method sueldo() = self.sueldoBase() + contrato.remuneracion(self)

Atención que esta es la primera vez que mandamos self por parámetro

Llamar la atención a esto y recordar que es una referencia al propio objeto

Probar que ahora la solución vuelve a funcionar

wollok:pepe> :rr
✓ Reloading environment
wollok:pepe> pepe.contrato(porcentual)
✓ 
wollok:pepe> pepe.sueldo()
✓ 1725

Y por qué no mandamos el sueldo base?

Otra variante que puede surgir es mandar por parámetro directamente el sueldo base

object porcentual {
    const porcentaje = 15

    method remuneracion(sueldoBase) = sueldoBase * porcentaje / 100
}

Y que el mensaje se mande en el código del método sueldo()

    method sueldo() {
        const base = self.sueldoBase() 
        return base + contrato.remuneracion(base)
    }

Esta también es una solución válida

Por detalles del ejercicio vamos a continuar pasando todo el empleado

Algunos posibles comentarios oportunos:

• Tanto el empleado como el sueldo base son objetos que se pasan por referencia: no hay objetos más pesados que otros
• Pepe sabe contestar más cosas que un número, por ejemplo su sueldo base
• Pasar el número evita que el contrato tenga que enviarle mensajes a pepe, eso reduce el acoplamiento

Tuvimos que tocar el código de pepe. Cómo podemos saber que no rompimos algo que ya estaba funcionando?

Esto es algo en lo que haremos foco la próxima clase: testing.

Por ahora decimos que, ante cada cambio, hay que probar todos los casos.

Sí, todos. Cuáles son?

Respuesta: 2 categorías * 3 contratos = 6 configuraciones posibles. O sea que al menos 6.

Acá se recomienda armar una sesión de consola con las 6 configuraciones y ver qué responde el programa (incluso sabiendo que todavía no codeamos el contrato por presentismo) y no cerrarla para poder jugar con el código y hacer :rr.

#TODO: Abrir un issue para que el :rr se frene ante un error (y pregunte si continuar / reiniciar / abortar)

El caso interesante es calcular el sueldo de pepe con el contrato básico, ya que rompimos el contrato (mensaje) que había entre los dos objetos.

pepe> pepe.contrato(basico)
✓ 
pepe> pepe.sueldo()
✗ Evaluation Error!
  wollok.lang.MessageNotUnderstoodException: basico does not understand remuneracion(arg 0)
    at pepe.pepe.sueldo() [pepe.wlk:5]

Rompimos el polimorfismo de los contratos 👎 Qué hacemos?

Bueno, una solución sencilla es cambiar el método en basico para que reciba un parámetro que no usa:

object basico {
    method remuneracion(empleado) = 1000
}

Mostrar que esto puede pasar, y si bien recibir parámetros que no se usan no es lo mejor, favorece una solución polimórfica, lo que sí es bueno.

De las pruebas anteriores llegamos al presentismo:

pepe> pepe.contrato(presentismo)
✓ 
pepe> pepe.sueldo()
✗ Evaluation Error!
  wollok.lang.MessageNotUnderstoodException: presentismo does not understand remuneracion(arg 0)
    at pepe.pepe.sueldo() [pepe.wlk:5]

A estas alturas, ya debería salir fácil que debemos implementar un método en presentismo

object presentismo { 
    method remuneracion(empleado) = ...
}

Pero acá sale una pregunta importante:

Quién tiene la responsibilidad de saber la cantidad de faltas?

Respuesta: Una primera intuición puede que nos diga el empleado. Pero esa información también podría estar en el mismo objeto presentismo

El modelo (de objetos) NO es la realidad

Para demostrar que si bien la realidad nos intuye a pensar de una forma, pero que nosotros podemos elejir cómo modelarla, vamos a ponerlo en el presentismo

object presentismo { 
    var property faltas = 0

    method remuneracion(empleado) = empleado.sueldoBase() - faltas
}

Y probar que funciona:

pepe> :rr
✓ Reloading environment
pepe> pepe.contrato(presentismo)
✓ 
pepe> pepe.sueldo()
✓ 3000

Mmmm... hay más casos para probar? 🤔

Respuesta: estaría bueno probar algún caso con faltas

pepe> presentismo.faltas(1)
✓ 
pepe> pepe.sueldo()
✓ 2900

Prestar atención a que, para probar el caso de pepe con una falta, hay que configurar el objeto presentismo, y no hace falta pasar por pepe para eso

En un programa de objetos, los objetos colaboran entre ellos para llegar al resultado. No hay objetos más importantes que otros

También se puede mostrar la variante donde las faltas la tenga pepe y mostrar cómo se usaría ese modelado.