UTNianos

Versión completa: [Paradigmas] [Resolución] Final 05/03/2011
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Chicos:

Final 05/03/2011

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)
Pirata (VI: cantBotines) >>
sosTemible
^ self cantBotines > 10

initialize
self cantBotines := 0.

Ejercicio >>
filtrarTemibles: unaColeccionDePersonas
^unaColeccionDePersonas collect: [ :unaPersona | unaPersona sosTemible]

Workspace:

ejercicio := Ejercicio new.

barbaRoja := Pirata new.
barbaRoja cantBotines: 15.

barbaNegra := Pirata new.
barbaNegra cantBotines: 8.

jackSparrow := Pirata new.
jackSparrow cantBotines: 2.

davidJones := Pirata new.
davidJones cantBotines: 25.

piratas := Set new.
piratas add: barbaRoja.
piratas add: barbaNegra.
piratas add: jackSparrow.
piratas add: davidJones.

piratasFiltrados := ejercicio filtrarTemibles: piratas.

b)
Cargo (VI: importante) >>
Getter y Setter.

Politico (VI: cargos) >>
initialize
self cargos := Bag new.

sosTemible
^ self cargos anySatisfy: [:unCargo |unCargo importante].

Goleador (VI: cantGoles, cantPartidos) >>
sosTemible
^ (self cantGoles / self cantPartidos) > 0.5

c) El concepto más fuerte que predomina en la implementación del punto b es el polimorfismo, ya que se pueden agregar nuevas clases que entiendan el mismo método, en este caso sosTemible, sin tener que modificar al resto de las clases, lo que le da extensibilidad y mantenibilidad al código.

El polimorfismo se ve en el método filtrarTemibles: ya que recibe una colección de objetos de distintas clases y cuando se realiza
^unaColeccionDePersonas collect: [ :unaPersona | unaPersona sosTemible]

cada objeto entiende el mensaje “sosTemible” indistitamente a qué clase pertenezca.

Punto 2.
1) La solución en el paradigma funcional es más declarativa ya que se centra en la declaración o descripción de “qué” es la solución del sistema, mientras que el paradigma imperativo se centra en “cómo” se resuelve el problema.

2)
Con la evaluación diferida, en funcional, se evalúa hasta que se encuentre el asiento disponible, por lo que no es necesario seguir evaluando.
En el paradigma imperativo, se evita realizar más comparaciones una vez que se encuentra la fila con el asiento disponible.
3) En la solución del paradigma funcional, busca por fila y en caso de no encontrar asiento disponible, consulta en la fila siguiente. En caso de no encontrar filas con asientos disponibles entraría en un loop infinito.
En caso de la solución del paradigma imperativo, también lo hay, en caso de que no haya asiento disponible ya que nunca saldría del while porque las filas seguirían aumentando.

Punto 3.
1) No es inversible para ningún caso.

hermano(X,Y).
hermano(X,bart).
hermano(bart,X).

Y la razón es porque cuando consulta por X \= Y, en el primer caso no tiene ligada ninguna variable, y para los restantes, sólo tiene una de las dos ligadas, por lo que no puede inferir el resultado, por lo que da siempre falso.

2) Devolvería false. La razón es que no puede inferir si son hermanos porque ni mariano ni nico están en la base de conocimientos como hijos de algún padre. Ejemplo: padre(raul,nico). Todo lo que no está en la base de conocimiento (“mundo acotado”) se considera como falso.

3)
padre(homero,bart).
padre(homero,lisa).
padre(homero,maggie).
madre(marge,bart).
madre(marge,lisa).
madre(lala,maggie).

hermano(X,Y):-
padre(Padre,X),
padre(Padre,Y),
madre(Madre,X),
madre(Madre,Y),
X \= Y.

hermanastro(X,Y):-
madre(Madre,X),
madre(Madre,Y),
padre(_,X),
padre(_,Y),
X \= Y.

hermanastro(X,Y):-
madre(_,X),
madre(_,Y),
padre(Padre,X),
padre(Padre,Y),
X \= Y.

Tanto entre hermano y hermanastro están codificados de la misma manera, con la misma cantidad de condiciones. La diferencia radica en que hermanastro tiene dos clausulas y utiliza variables anónimas ya que para el caso de ser hermanastros por parte de la madre, solo interesa que sean hijos de la misma madre y el padre no interesa pudiendo ser el mismo ya que el enunciado lo dice así (en este caso, aparte de ser hermanos, serían hermanastros). Lo mismo para el caso que sean hermanastros por parte de la madre.
(29-02-2012 20:05)leandrong escribió: [ -> ]Ejercicio >>
filtrarTemibles: unaColeccionDePersonas

^unaColeccionDePersonas collect: [ :unaPersona | unaPersona sosTemible]

Holass, yo aca pondria un select: en vez de un colect, porq el select es basicamente el filter en objetos
(02-03-2012 21:46)mahaad escribió: [ -> ]
(29-02-2012 20:05)leandrong escribió: [ -> ]Ejercicio >>
filtrarTemibles: unaColeccionDePersonas

^unaColeccionDePersonas collect: [ :unaPersona | unaPersona sosTemible]

Holass, yo aca pondria un select: en vez de un colect, porq el select es basicamente el filter en objetos

Tenés razón, el collect te devolvería una colección del tipo (true, true, false, false)

Es un select.
[/quote]
c) El concepto más fuerte que predomina en la implementación del punto b es el polimorfismo, ya que se pueden agregar nuevas clases que entiendan el mismo método, en este caso sosTemible, sin tener que modificar al resto de las clases, lo que le da extensibilidad y mantenibilidad al código.

El polimorfismo se ve en el método filtrarTemibles: ya que recibe una colección de objetos de distintas clases y cuando se realiza
^unaColeccionDePersonas collect: [ :unaPersona | unaPersona sosTemible]

cada objeto entiende el mensaje “sosTemible” indistitamente a qué clase pertenezca.
[/quote]

Te faltan conceptos, delegacion y encapsulamiento. Esta bien que el mas importante es el polimorfismo pero los otros tambien importan.
Yo en lugar de hacer:

piratas := Bag new.

lo crearía como un Set, que no admite repetidos.

piratas := Set new.
(19-02-2015 13:40)LAUS escribió: [ -> ]Yo en lugar de hacer:

piratas := Bag new.

lo crearía como un Set, que no admite repetidos.

piratas := Set new.

Es verdad, pero como es el workspace no hay tanto problema, porque le agregué yo a mano los piratas.
URLs de referencia