Gente, no tengo idea como encarar este ejercicio de objetos, a ver si algún alma bondadosa e inteligente me ayuda, cualquier aporte será bien recibido . El enunciado dice así:

En un juego de ping pong, bidimiensional y muy simple, se tiene el sig. requerimiento: cada vez que la pelota es golpeada por la paleta, su dirección se modifica según la inclinación de la paleta.

#Paleta
golpearA:unaPelota
unaPelota direccion := unaPelota direccion + self inclinacion

#Pelota (vi:direccion)
direccion:algo
direccion:=algo

direccion
^direccion

a- ¿Funciona? En caso afirmativo mostrar un ejemplo de uso y en caso negativo corregirla.
b- ¿Qué se puede decir del encapsulamiento y la delegación? Hacer una nueva versión para aplicar de la mejor manera estos conceptos.
c- ¿Tiene efecto colateral golpear la pelota? ¿Dónde?

2. Hacer una solución en Haskell que resuelva el mismo problema. Explicar que sentido tienen los conceptos anteriores en la presente solución.

3. Un fanático de béisbol quiere plantear modificaciones en el juego, como por ejemplo golpear la pelota con un bate. En este caso, la dirección de la pelota se modifica según un angulo del golpe que depende de la posición de la pelota en relación al bate. Se planteó esta solución:

#Pelota
esGolpeadaPor:unBate
direccion := direccion + unBate anguloDeGolpe: self posicion

A su vez un jugador puede tener en su mano una paleta o un bate y quiere poder pegarle a una pelota con él.
¿La solución planteada en objetos soporta este requerimiento? Justificar en caso afirmativo, o completarla o corregirla en caso contrario.

Gracias, gracias, gracias!

yo diria que no funciona, porque no se puede modificar el valor de una clase desde otra, solo se puede desde esa misma, por lo tanto la solucion seria..

#Paleta(vi:inclinacion)
golpearA:unaPelota
unaPelota direccion : unaPelota direccion + self inclinacion

inclinacion
^inclinacion

#Pelota (vi:direccion)
direccion:algo
direccion:=algo

direccion
^direccion

eso seria que no posee la propiedad de encapsulamiento, lo que si se ve en la solucion con los metodos getters y setters,
la delegacion se ve ya que el metodo golpearA delega mediante un mensaje la responsabilidad de modificar el valor de la direccion?(nose si esta bien esto)

Tiene efecto colateral porque la direccion no solo se usa en la clase pelota que es donde se "declara" sino que tambien en la de paleta cuando la llamas para que sea modificada

alguien me corrige cualqier cosaa?

tenes el resto del final??

Lo miré asi nomas, pero tiro lo que me parece.
1-
a- Creo que no funciona principalmente por:
"unaPelota direccion := unaPelota direccion + self inclinacion"

Los atributos en SmallTalk creo que son Protected, con lo cual desde un objeto que no comparte clase no podrías setearlo directamente, además la pelota ya tiene un metodo setter.


b- Encapsulamiento y delegación no tiene mucha que digamos. Está todo súper acoplado. Y nadie delega nada, bah, la pelota delega su comportamiento a la paleta

c- Tiene efecto colateral de manera evidente en por setter, como no es stateless lo que devuelve en ^direccion depende de su estao interno.


2- Me parece que lo que les interesa aca es el tema del efecto de lado. En haskell no dependes de ningun estado interno, la misma llamada devuelve siempre lo mismo.... transparencia referencial... blah blah....
No es que no puedas hacer algo que te de funcionalidad similar, pero cada llamda tendría que tener toda la info necesaria para calcular lo que querés.
Por ejemplo, podrías pasarle a una funcion una lista de todos los angulos de golpes que vaya a recibir y que te dé la posición final, pero, conceptualmente la pelota como una cosa que va teniendo posiciones en un determinado momento se comporta como un ente con un estado y desde ese punto de visto no da haskell para plantearlo.


3- Bueno está esta planteada en relacion al 1-a. me parece. Como está todo acoplado, si agregas comportamientos diferentes vás a tener que tocar todo el codigo.
Osea, la pelota termina teníendo la responsabilidad de saber quien le está pegando para determinar su direccion.

No te puedo dar mucho presicion en esto, porque suelo diferir en los criterios de la catedra.

Me parece que es un tema de diseño y de como entendes el problema. Estimo que quieren ver polimorfismo lo mas "completo" posible.

Pero entendiendo que cualquier juego que conste en golpear una pelota no requiere de una entidad pelota con mucho comportamiento más que informar y recibir donde se tiene que poner, no debería ser un problema delegar la responsabilidad de la posicion en el objeto que la golpea (como en el 1-a) y que las cosas que le pegan comparte el tipo de los que "golpeanA" algo.

Creo que todo depende de como lo justifiques, si te dicen, en un nuevo juego las pelotas pueden ser de tenis, bowling o ping pong....Ahi te "caga" la delegacion y te obligaría a un diseño diferente.

Si, lo de delegación lo pensé igual q vos, el resto de los puntos no tengo las mas pálida idea, gracias!!! Ahí te adjunte un txt (No le pude sacar foto ) con los puntos 1 y 3 restantes.

Gracias por el TXT.

Si querés comentar que hiciste con los demás tambien viene bien

En el ejercicio 1 :
tareaSiguiente(encuesta,Tarea) te va a devolver
Tarea=analisis
Tarea=diseño
lo cual es correcto
tareaSiguiente(Tarea,construccion) te devuelve
Tarea=diseño
Tarea=analisis lo cual no es lo q vos estas buscando. Faltaria la tarea aprobarParadigmas lo q pasa que en
tareaSiguiente(TareaAnt,TareaSig):-proyecto(P,tarea(TareaSig,Tareas)),
member(TareaAnt,Tareas),
proyecto(P,tarea(TareaAnt,_)).

el último predicado proyecto está al pedo, desde el vamos que donde dice P podría ir un _ porq no se usa nunca. Cuando empieza a evaluar tareaSiguiente liga solo TareaSig=construccion, encuentra un predicado en la base de conocimientos con esa tarea y despues cuando empieza a evaluar el member te va tirando diseño, analisis, cuando llega a aprobarParadigmas como proyecto(P,tarea(TareaAnt,_)) te liga TareaAnt=aprobarParadigmas el tipo no encuentra ninguna tarea con ese nombre y no te lo muestra la manera correcta de hacerlo es:

tareaSiguiente(TareaAnt,TareaSig):-proyecto(_,tarea(TareaSig,Tareas)),
member(TareaAnt,Tareas).

del mismo modo tareaSiguiente(aprobarPâradigmas, construccion) y tareaSiguiente(equipamiento,ejecucion) te van a dar falsas cuando tendrían q devolver true.

En el EJERCICIO 3 el tipo de g es (Num a) => a -> (a -> Bool) -> [a]
y bueno, en las consultas
f 4 lista infinita de valores consecutivos a partir de 4
f "hola" error de tipos. f solo acepta números por la función (+)
take 4 . f 4 error, faltan los parentesis -> (take 4.f) 4
(take 3.f) 4 -> [4,5,6]
...
g 4 -> te devuelve g 4, porq falta un parámetro, acá supongo q podés meter chamullo de aplicación parcial, currificación, bla bla.

y en el item 3 cuando querés consultar g(8,Lista). no termina jamás la consulta porq se esta trabajando con una lista infinita y en prolog esto rompe porq trabaja con el concepto de evaluación ansiosa.

Hasta ahí llegué yo...igual no se confíen mucho porq me fué como el orto pero bueno...

De donde sacaste las consignas/Las podrias subir??

Muchisimas gracias, Eric!

puede ser que sea asi el 1 ? puede estar mal, cualqier cosa corrijanmee
para que la 4 deje de ser falsa habria que agregar esto


tareaSiguiente(TareaAnt,TareaSig):-proyecto(P,tarea(TareaSig,Tareas)),
member(TareaAnt,Tareas),
proyecto(P,tareaExterna(TareaAnt,_)).


la P es importante, ya que si agregas mas proyectos pero con iguales tareas te podria dar mas resultados que los que necesitas.

y para que la 3 deje de ser falsa

proyecto(saeta,tarea(aprobarParadigmas,[])).

las respuesas eran falsas x el concepto de universo cerrado(no esta en la base de conocimientos).

y el predicado si es inversible,

Eric, fijate q subi un txt con el ejercicio 1 y ejercicio 3, el 2 es justamente el primer comentario del thread

Hola!

El ejercicio de objetos, planteado como esta, no funciona por una sencilla razón: unaPelota dirección devuelve aquel objeto al que la v.i. 'direccion' de la pelota esta apuntando (probablemente sea un número). Y después trata de asignarle a ese objeto otro objeto (unaPelota dirección+ Self inclinación), lo cual -aparte de ser cualquier cosa- no funciona.

Una forma de corregirlo (no la mejor) es hacer:

unaPelota dirección: unaPelota dirección+self inclinación.

Donde usamos el setter correspondiente.

Obviamente el encapsulamiento es un asco, jaja, porque no encapsula nada y permite que la paleta cambie valores que son propios de la pelota. Tampoco delega correctamente, porque lo lógico sería que la paleta delegue la reasignacion de la variable en la pelota, ya que es una variable de la pelota.

Una mejor solución sería:

Paleta>>golpearA: unaPelota
unaPelota cambiarDireccionEn: self inclinación.

Pelota>> cambiarDireccionEn:unosGrados
self dirección: (unosGrados+self dirección).

Golpear la pelota tiene efecto en la pelota, jaja. Al golpear la pelota, se asigna destructivamente una variable de la pelota y se genera un cambio que perdura más allá de la ejecución del método. Vale aclarar también que una característica interesante del paradigma es que nos permite tener abstracciones y un comportamiento más cercano al dominio: es natural sin saber nada de programación, pensar que golpear una pelota generara un efecto sobre la pelota.


En Haskell una posible solución que plantee yo implicaba modelar las paletas y las pelotas como tuplas, por ejemplo pelota=(color,dirección) paleta=(jugador,inclinación) (para darle un poco más de sentido y gracia )

Y una solución sería

golpear (color,dirección) (_,inclinación)= (color,dirección+inclinacion)

Obviamente acá no hay efecto. Al golpear una pelota lo que hacemos es generar una nueva pelota con la dirección modificada, pero jamás cambiamos a la pelota original. De hecho no tiene sentido siquiera pensar que la pelota 'tenga ' una dirección o que la paleta 'tenga ' una inclinación, no hay variables que puedan verse como espacios de memoria que guardan valores. En funcional el conceptod e variable es otro. El encapsulamiento en funcional no existe, y la delegacion se hace sobre otras funciones, por ejemplo, podríamos decir que en nuestra solución delegamos en la función (+).

En el último punto básicamente faltaría modelar al jugador y el bate, y hacerlo de forma polimorfica.