29-02-2012, 16:37
Chicos:
https://docs.google.com/document/d/10Hxp...edit?pli=1
Acá está el final de Paradigmas del 03/12/2011. Lo resolví pero no sé si está del todo bien. Si me pueden dar una mano se los agradecería:
Punto 1.
a.-
En tieneMuchosPaisajes hay asignación destructiva en
1) pai := true;
2) pai := false
Pai comienza en true, y en caso de que no haya un paisaje que no sea lindo cambiar el valor a false.
En escultural hay asignación destructiva en
1) cantMuseos := 0.
2) cantMuseos := cantMuseos + ciudad museos size
Se utiliza para acumular la cantidad de Museos que hay en un Tour.
b.-
tieneMuchosPaisajes
^self ciudades allSatisfy: [ :unaCiudad | unaCiudad tieneLindosPaisajes].
esCultural
^ (self ciudades inject: 0 into: [ :acum :ciudad |acum + ciudad museos size ]) > self ciudades size.
c.- Considerando los métodos nuevos del punto b, al no haber asignación destructiva se asegura que no haya efecto de lado dentro de cada método pero si consideramos los métodos viejos del punto a hay asignación destructiva por lo que se observa que hay efecto de lado dentro de cada método.
d.- El concepto lo encuentro en el metodo "tienePlaya". Aqui puedo observar que los objetos polimorficos tour y ciudad entienden el mensaje "tienePlaya".
e.-
Tour>> leCopaA: unaPersona
^ (unaPersona gustos allSatisfy: [:unGusto | unGusto = #Cultura ifTrue:[self esCultural ] or: unGusto = #Paisajes ifTrue: [self tieneMuchosPaisajes ] or: unGusto = #Playa self tienePlayas]).
Lo que habría que cambiar es que ahora gustos en vez de ser un sólo, tendría que ser una colección de gustos (que podría, obviamente contener uno solo)
f.-
>>Persona(VC: gustos)
teCopa: unTour
^(self gustos allSatisfy :[unGusto | unGusto teSatisface: unTour ].
La persona es quien sabe si le gusta o no un tour. Por lo que se delega la responsabilidad a la persona.
>>Cultura
teSatisface: unTour
^(unTour escultural)
>>Paisajes
teSatisface: unTour
^(unTour tieneMuchosPaisajes)
>>Playa
teSatisface: unTour
^(unTour tienePlays)
Se crea una clase por cada tipo de gusto, y de esta forma se puede usar polimorfismo en el método teCopa: de la clase Persona, ya que gustos es una colección de los 3 tipos de gustos (Cultura,Paisajes y Playa) y los tres entienden el mensaje “teSatisface:”
g.-
En primer lugar, hay una mejor delegación de responsabilidades, ya que no es responsabilidad del Tour saber si a una Persona le gusta dicho Tour, sino que es responsabilidad de la persona. Por otra parte el uso de polimorfismo permite que se puedan agregar nuevos gustos sin tener que modificar el código del programa (en el propuesto había que agregar más condiciones) ya que con sólo agregar el nuevo gusto sería suficiente lo dota a esta solución de mayor extensibilidad (posibilidad de agregar nuevos gustos) y mantenibilidad (facilidad de agregarlo).
Punto 2.
a.- Hay aplicación parcial en
snd.buscaren promedioPuntos
Porque map/2 recibe una función y una lista. En este caso la función es buscaren/2 que tiene dos parámetros, pero ya tiene aplicado uno de sus parámetros (promedioPuntos) y el otro sería cada elemento de la lista equipo.
equipoGroso equipo =(sum. map (snd . buscaren promedioPuntos)) equipo >=100
Sin la aplicación parcial, no podría realizarse la función, ya que es necesario que cada elemento de la lista equipo sea buscado en la lista de promedioPuntos para poder llevar acabo el map y así obtener una nueva lista con solamente los jugadores del equipo deseado.
b.- En Haskell se usa en las funciones map y filter. Tanto en map como en filter, se obtiene una lista, en este ejemplo, en el map consigue la lista de puntos del equipo, y el filter una lista con la tupla de un jugador.
En Prolog se usa en el predicado findall. La ventaja radica en que permite armar una lista con los puntos de todos los jugadores del equipo a través de un solo predicado.
De no existir este concepto, en ambos lenguajes no habría forma de formar las listas.
c.-En Prolog se puede preguntar si existe algún equipo que sea groso gracias al concepto de inversibilidad:
?- equipoGroso(X).
false.
Mientras que en Haskell no se puede ya que no posee inversibilidad.
d.- En Prolog, si bien la resolución del ejercicio es bastante expresiva, se la podría aumentar al crear nuevos predicados:
equipoGroso(Equipo):-
listaPtsEquipo(Equipo,ListaPts),
sumlist(ListaPts, TotalPts),
TotalPts >= 100.
listaPtsEquipo(Equipo,ListaPts):-
findall(Pts, jugadorPts(_,Equipo,Pts), ListaPts).
jugadorPts(Jug,Equipo,Pts):-
jugador(Jug, Equipo),
promedioPuntos(Jug, Pts).
Por el contrario en Haskell, hay muy poca expresividad, por lo que sería necesario crear nuevas funciones para aumentarla.
spurs = ["ginobili", "duncan"]
bulls = ["rose","deng"]
promedioPuntos = [("ginobili", 24), ("duncan", 33),("rose",60),("deng",45)]
equipoGroso equipo = totalPuntos equipo >=100
totalPuntos = sum. map (puntos.buscaren promedioPuntos)
buscaren listaJugadores jugador = (head.filter ((==jugador).apellido)) listaJugadores
apellido = fst
puntos = snd
https://docs.google.com/document/d/10Hxp...edit?pli=1
Acá está el final de Paradigmas del 03/12/2011. Lo resolví pero no sé si está del todo bien. Si me pueden dar una mano se los agradecería:
Punto 1.
a.-
En tieneMuchosPaisajes hay asignación destructiva en
1) pai := true;
2) pai := false
Pai comienza en true, y en caso de que no haya un paisaje que no sea lindo cambiar el valor a false.
En escultural hay asignación destructiva en
1) cantMuseos := 0.
2) cantMuseos := cantMuseos + ciudad museos size
Se utiliza para acumular la cantidad de Museos que hay en un Tour.
b.-
tieneMuchosPaisajes
^self ciudades allSatisfy: [ :unaCiudad | unaCiudad tieneLindosPaisajes].
esCultural
^ (self ciudades inject: 0 into: [ :acum :ciudad |acum + ciudad museos size ]) > self ciudades size.
c.- Considerando los métodos nuevos del punto b, al no haber asignación destructiva se asegura que no haya efecto de lado dentro de cada método pero si consideramos los métodos viejos del punto a hay asignación destructiva por lo que se observa que hay efecto de lado dentro de cada método.
d.- El concepto lo encuentro en el metodo "tienePlaya". Aqui puedo observar que los objetos polimorficos tour y ciudad entienden el mensaje "tienePlaya".
e.-
Tour>> leCopaA: unaPersona
^ (unaPersona gustos allSatisfy: [:unGusto | unGusto = #Cultura ifTrue:[self esCultural ] or: unGusto = #Paisajes ifTrue: [self tieneMuchosPaisajes ] or: unGusto = #Playa self tienePlayas]).
Lo que habría que cambiar es que ahora gustos en vez de ser un sólo, tendría que ser una colección de gustos (que podría, obviamente contener uno solo)
f.-
>>Persona(VC: gustos)
teCopa: unTour
^(self gustos allSatisfy :[unGusto | unGusto teSatisface: unTour ].
La persona es quien sabe si le gusta o no un tour. Por lo que se delega la responsabilidad a la persona.
>>Cultura
teSatisface: unTour
^(unTour escultural)
>>Paisajes
teSatisface: unTour
^(unTour tieneMuchosPaisajes)
>>Playa
teSatisface: unTour
^(unTour tienePlays)
Se crea una clase por cada tipo de gusto, y de esta forma se puede usar polimorfismo en el método teCopa: de la clase Persona, ya que gustos es una colección de los 3 tipos de gustos (Cultura,Paisajes y Playa) y los tres entienden el mensaje “teSatisface:”
g.-
En primer lugar, hay una mejor delegación de responsabilidades, ya que no es responsabilidad del Tour saber si a una Persona le gusta dicho Tour, sino que es responsabilidad de la persona. Por otra parte el uso de polimorfismo permite que se puedan agregar nuevos gustos sin tener que modificar el código del programa (en el propuesto había que agregar más condiciones) ya que con sólo agregar el nuevo gusto sería suficiente lo dota a esta solución de mayor extensibilidad (posibilidad de agregar nuevos gustos) y mantenibilidad (facilidad de agregarlo).
Punto 2.
a.- Hay aplicación parcial en
snd.buscaren promedioPuntos
Porque map/2 recibe una función y una lista. En este caso la función es buscaren/2 que tiene dos parámetros, pero ya tiene aplicado uno de sus parámetros (promedioPuntos) y el otro sería cada elemento de la lista equipo.
equipoGroso equipo =(sum. map (snd . buscaren promedioPuntos)) equipo >=100
Sin la aplicación parcial, no podría realizarse la función, ya que es necesario que cada elemento de la lista equipo sea buscado en la lista de promedioPuntos para poder llevar acabo el map y así obtener una nueva lista con solamente los jugadores del equipo deseado.
b.- En Haskell se usa en las funciones map y filter. Tanto en map como en filter, se obtiene una lista, en este ejemplo, en el map consigue la lista de puntos del equipo, y el filter una lista con la tupla de un jugador.
En Prolog se usa en el predicado findall. La ventaja radica en que permite armar una lista con los puntos de todos los jugadores del equipo a través de un solo predicado.
De no existir este concepto, en ambos lenguajes no habría forma de formar las listas.
c.-En Prolog se puede preguntar si existe algún equipo que sea groso gracias al concepto de inversibilidad:
?- equipoGroso(X).
false.
Mientras que en Haskell no se puede ya que no posee inversibilidad.
d.- En Prolog, si bien la resolución del ejercicio es bastante expresiva, se la podría aumentar al crear nuevos predicados:
equipoGroso(Equipo):-
listaPtsEquipo(Equipo,ListaPts),
sumlist(ListaPts, TotalPts),
TotalPts >= 100.
listaPtsEquipo(Equipo,ListaPts):-
findall(Pts, jugadorPts(_,Equipo,Pts), ListaPts).
jugadorPts(Jug,Equipo,Pts):-
jugador(Jug, Equipo),
promedioPuntos(Jug, Pts).
Por el contrario en Haskell, hay muy poca expresividad, por lo que sería necesario crear nuevas funciones para aumentarla.
spurs = ["ginobili", "duncan"]
bulls = ["rose","deng"]
promedioPuntos = [("ginobili", 24), ("duncan", 33),("rose",60),("deng",45)]
equipoGroso equipo = totalPuntos equipo >=100
totalPuntos = sum. map (puntos.buscaren promedioPuntos)
buscaren listaJugadores jugador = (head.filter ((==jugador).apellido)) listaJugadores
apellido = fst
puntos = snd