Buenas, dejo una resolución al final por si alguno lo hizo y quiere comparar:
Funcional:
1)a)
((pdep ["polimorfismo","inversibilidad"]).(compliqueti101 5)) jonSnow
1)b) Debido a que Haskell no tiene efecto, LUEGO de la consulta: dedicación jonSnow devuelve 800
2) Verdadero. Se puede utilizar aplicación parcial y hacer lo siguiente:
type Materia = Alumno -> Alumno
Entonces una Cursada seria una lista de materias del estilo:
cursada = [(pdep ["inversibilidad","polimorfismo"]),compliqueti101 8, compliqueti101 25]
Se les aplica parcialmente el valor requerido para que todas sean del tipo Materia y puedan ser utilizadas en una lista.
3)a) Para que termine de evaluarse, debe encontrar al menos un elemento que sea "nothing" en la lista entonces se puede hacer que la lista sea:
"nothing" ++ listaInfinita
Al hallar como primer valor "nothing" (porque utiliza evaluación diferida) corta la búsqueda y ya retorna el valor.
3) b)
De forma análoga, si coloco el valor al final de la lista:
listaInfinite ++ "nothing"
esta nunca terminará de ejecutar ya que siempre va a continuar buscando el valor.
Lógico:
1)
Individual: deudaTotal(george,150) -> False
Existencial: deudaTotal(george,Deuda) -> 32.
2) Falso, si bien la solución resuelve todos los precios EXISTENTES HASTA EL MOMENTO, no está tomando a los libros de forma polimorfica, ya que esta creando una lista por cada tipo de libro.
3)
deudaTotalParte2(Usuario,Deuda):-
esComprador(Usuario),
findall(Precio,(compro(Usuario,Titulo),(precioLibro(Titulo,Precio))),DeudasTotales),
sum_list(DeudasTotales,Deuda).
precioLibro(Titulo,Precio):-
libro(Titulo,digital(_,KB)),
Precio is (KB/1024) *10.
precioLibro(Titulo,Precio):-
libro(Titulo,papel(Paginas,_)),
Precio is Paginas *0.05.
esComprador(Usuario):-
compro(Usuario,_).
Objetos:
1) a) delegación: cuando calcula las notas de cada materia, se debería delegar ese calculo en una función materiaAprobada() que implemente según el criterio decidido si está aprobada o no.
Polimorfismo: Hay un mal uso del polimorfismo, ya que se está consultando por la clase de la materia para devolver un resultado, en vez de pedirle a cada materia que realice una acción particular.
1)b) Mal manejo de errores, ya que se requiere devolver un booleano para el método "seRecibio()" del alumno. Que no haya aprobado es uno de los valores contemplados dentro de la solución, no debe cortar el flujo de ejecución.
1)c) Poco declarativa ya que hay mucho detalle algorítmico presente en la solución, por ejemplo, en el uso de acumuladores.
2)
Class Alumno{
const cursadas = []
method seRecibio() = cursadas.all({ cursada => cursada.fueAprobada()}=
}
Class Cursada{
var materia;
var dedicacion;
const notas = []
method fueAprobada(){
return materia.estaAprobado(dedicacion,notas);
}
}
Abstract Class Materia{
method estaAprobado(dedicacion,notas);
method aproboParciales(notas){
return notas.all({ nota -> nota >= 6});
}
}
Class IntroduccionALaComplejidad implements Materia{
method estaAprobado(dedicacion,notas){
return aproboParciales(notas) && dedicacion >= 100;
}
}
Class Compliqueti101 implements Materia{
method estaAprobado(dedicacion,notas){
return aproboParciales(notas) && notas.any({ nota -> nota == 10 });
}
}
Class ZarazaTotal implements Materia{
method estaAprobado(dedicacion,notas){
return notas.any({ nota -> nota >= 6});
}
}
3)
* El alumno permanece idéntico en la solución..
* La cursada trata a la materia de forma indistinta, ya que todas implementan el método estaAprobado(dedicación,notas) por lo que, a futuro, se pueden agregar mas materias sin necesidad de cambiar el código.
* Cada materia implementa su criterio de aprobación de forma indistinta con los parámetros que obtiene (nivel de dedicación y notas de la cursada)
* Se suprimió el uso indebido de excepciones ,ya que desaprobar una materia es un valor esperado.
* Se mejoró la declaratividad, ya que el detalle algorítmico es propio de cada materia y se enfoca mas en el QUE hay que hacer y no en el COMO (preguntar que materia es para obtener un resultado).
Saludos!
![[-]](images/collapse.gif)
