lucasgaleano / paradigmas_tps Goto Github PK

Mejorar el orden de los parametros para poder usar Point FREE

• Reutilizar el predicado que nos dice si una persona mira o planea ver una serie
• La condicion not(leSpoileo..... esta repetida en televidenteResponsable, deberia estar en un predicado auxiliar para reutilizarla
• Falta codificar el predicado cosasFuertes

Mejorar la expresividad (Yo entendi que se le aplica un evento a un usuario, y nos esta devolviendo un evento.. .WTF???)

Aplicar el concepto de evaluacion diferida

Usar max

Si en el punto en el que tienen que encontrar el mejor/peor usuario para una determinada lista desarrollan una funcion generica que encuentre el minimo/maximo de una lista ante un determinado criterio deberian poder reutilizarla en este punto sin tener que usar fold ni ninguna otra funcion adicional que recorra la lista

No alcanza con que haya sucedido algo en una serie, fijense que el enunciado describe condiciones adicionales segun el tipo de evento que sucedio

Usar FOLD

Recuerden leer en la guia de lenguajes que hace la funcion flip (Guiño guiño)

Armar una funcion recursiva sin caso base

(++)

Si aca en lugar de generar una lista van incrementando un contador y lo devuelven cuando se cumple la condicion sale mas facil y conciso

En la entrega 2, se habla de que siempre al comprar un hechizo dejamos el que tenemos como parte de pago.

¿Hace falta saber acerca del canje, o simplemente tenemos que comprar el hechizo y que pase lo que tenga que pasar?

Imaginen que nos dicen: "Compra 3kg de papa, un hechizo de logos, 3 artefactos, y una docena de medialunas". No importa qué pasa en cada compra, estaría bueno pedir que se compre de la misma manera en todos.

Y ahí vemos que cada compra tiene cosas en común:

• Se gasta plata en algo. Esto es siempre igual, gastamos dinero. Y si no nos alcanzaba, habría que cortar con excepción.
• Obtenemos esa cosa. Esto a veces hace que se nos agregue un artefacto, y a veces que tengamos un nuevo hechizo preferido. Suena a que es responsabilidad de ellos decirnos qué pasa al comprarlos.

Luego, está el tema de cuánto cuestan:

• Los artefactos tienen cierto precio de lista sencillo.
• Los hechizos, en cambio, tienen un precio final que se puede pensar como el precio de lista - un descuento por lo que nos dejarían en parte de pago. Obviamente, si el precio final tiene que ser 0 o más (nunca devolvemos plata).

¿Me explico? Avisen por mail o en la clase si hay dudas con esto.

Los predicados en logico se usan para relacionar atomos y/o para describir alguna propiedad que tenga alguno en particular, este predicado puntualmente se usa para describir que series son populares, con lo cual deberia ser de aridad 1 y tener multiples clausulas, una por cada serie que es popular. Ademas piensen que pasaria si el dia de mañana tengo que agregar mas series que sean populares, tendria que modificar todos los lugares donde aparezca este predicado para agregarle parametros, lo cual nos complica la solucion sin otorgarnos ningun beneficio

Cuando le piden a un personaje que compre, se lo delegan 100% a la feria. Así que el método para que el personaje compre parecería estar de más, no aporta nada en verdad.

Pero viendo a la feria: ¿Qué hace?

• Verifica si tiene dinero suficiente (el personaje).
• Tiene cierta lógica si no le alcanza (en un futuro lanzará excepción, por algo del personaje).
• Gasta el dinero (del personaje).
• El dinero gastado difiere según la cosa a comprar.
• Adquiere el producto (para el personaje, de diferentes maneras dependiendo de qué compra).

Suena a que muchas cosas dependen de las otras entidades. Revisen si siguen necesitando a la feria o no.

En logico si un predicado relaciona a un atomo con dos o mas preferimos escribirlo utilizando multiples clausulas en lugar de una lista para que el motor se encarge de relacionarlos en lugar de tener que trabajar extra nosotros desarmando la lista. Dicho sea de paso esto ultimo no lo hicieron, con lo cual ningun punto del TP funciona.

Ademas deberian ser coherentes con sus elecciones, si el predicado relaciona a juan, nico y maiu con una lista entonces a gaston deberia relacionarlo con una lista tambien, en este caso de un solo elemento

Estan harcodeando como loco!!

No es necesario separar la lista en el parametro.

Estan pasandole como segundo parametro a filter, la lista de usuarios transformados. Arreglen eso!!!

sacaron todas las funciones que realicé donde estaban los cambios para los issues

suena mucho a peorSegun (Guiño guiño)

Veo que tienen un solo archivo "rolando" con todo. Separen.

Podrían no hacer un archivo por clase/WKO, hay varios que son muy chicos. Pero al menos separen agrupando con algún criterio.

Ejemplo: Persona por un lado, hechizos por otro, artefactos de lucha en otro archivo, etc.

También, en los archivos de tests, pueden usar nombres comenzando con "parte1..." así es más rápido abrir cada parte al corregir

Pedirle que compre algo siendo que no le alcanza, es un flujo que no queremos que pase. Siempre que le pedimos a un personaje que compre, es porque efectivamente puede comprarlo.

Para mostrar que el flujo no es el deseado, corten con una excepción, y testéenla.

Además, tienen bastante código repetido:

	method vende(personaje, artefacto) {
		if(self.loPuedeComprar(personaje, artefacto.precio())){
			self.cobraPrecio(personaje,artefacto.precio())
			personaje.agregaArtefacto(artefacto)
		}
	}
	
	method canjea(personaje,hechizo){
		var nuevoPrecio = self.precioRetribuido(hechizo,personaje.hechizoPreferido())
		if(self.loPuedeComprar(personaje,nuevoPrecio)){
			self.cobraPrecio(personaje, nuevoPrecio)
			personaje.hechizoPreferido(hechizo)	
		}
	}

Hablo más de esto en el siguiente issue.

Aplicar composicion y ver si se puede mejorar un poquito

El predicado esta bien resuelto, un pequeño detalle nada mas: Lo ideal aca seria que el predicado que tenga multiples clausulas sea uno auxiliar y no el que resuelve el punto, de esta forma queda todo mas expresivo, se lee mas facilmente la solucion y tambien pueden reutilizarlo en caso de que sea necesario. Creen un predicado auxiliar (podria llamarse miraOPlaneaVer por ejemplo) que nos diga si una persona mira o planea ver una serie y fijense que les va a quedar mejor

Concatenar los bloques del blockChain, para despues aplicarselos al usuario

Pista: Se puede reutilizar lo anteriormente definido

Evaluacion diferida

Veo que en la segunda sección de tests hicieron esto en el fixture:
rolando.removeTodosLosArtefactos()

Ahí creo que están un poco a la defensiva de que quizá el día de mañana la lista aparezca con cosas.

Si quieren, siguiendo a la defensiva, podrían inicializar al Personaje usando el constructor de parámetros nombrados para decir cuáles son sus artefactos en la misma creación.

Aunque para eso, tendrían que repensar lo del artefacto "ninguno", y resolver su duda:
// como hago para no necesitar el objeto 'ninguno' en artefactos, por el tema del espejoPreferido

No me queda claro el problema. ¿Sería que si la lista es vacía, el max falla? Si es así, no es un problema. Buscar el máximo de una lista vacía no tiene sentido, está bien que falle. ¿Era eso u otra cosa? Si quieren lo vemos en clase.

Punto equivocado, no le den bola a este issue

Las constantes indican que "esta referencia nadie la va a pisar en ningún momento con otra cosa". Nos da seguridad al ver el código de que siempre le hablamos al mismo objeto. Así que si una referencia puede ser constante, la recomendación es hacerla constante.

Recordemos que constante no es sinónimo de inmutable. El objeto referenciado puede mutar dependiendo de cómo esté hecho. Pero igual nos ayuda.

Considerar aplicar los eventos a la billetera y no al usuario

La idea es que ande todo lo de la última entrega, y que lo anterior (con sus tests) den verde de nuevo.

No importa si ya avanzaron sobre la entrega 3, igual dejen la última versión estable y miramos eso.

Si piensan a la blockchain como un gran bloque aplanandolo con concat se puede resolver mas facil de esta forma:

aplicarBlockChain unaBlockchain unUsuario = aplicarBloque (concat unaBlockchain)

Hacer algo parecido a lo anterior:

Pista: Reutilizar MejorSegun

map cof cof

Si bien está comentado en otro issue, lo dejo aparte para hacer seguimiento más fácil.

Necesitan un refuerzo que represente "ningún refuerzo", pero para los artefactos y hechizos no debería hacer falta.

La armadura y el libro de hechizos deberían arrancar con colecciones vacías.

Usar variable anonima, la serie en este caso no nos interesa

Armar una funcion saldoDespuesDe que reciba un numero y una blockchain

Debe devolver una billetera

Usen variables anonimas, aca el otro y la serie no nos interesan

Definir una funcion "mejorSegun" (Reutilizable) que reciba un criterio, y una lista, y devuelve el elemento mas grande segun ese criterio. Pueden usar FOLD o FIND (Desafio: Usen find)

Definir una funcion para saber quien es el tipo mas adinerado, usando la funcion definida mas arriba

Si bien no esta mal resuelto no esta bien usado el fold aca, piensen que en esta funcion ustedes quieren saber si un usuario es el mejor segun un determinado criterio (porque estan usando esta funcion como condicion del find, entonces imagino que su razonamiento pasaba por ese lado), entonces la condicion que tendrian que expresar en este punto es que ese usuario sea mejor que todos los elementos de la lista, lo cual es mas natural expresar con un all que con un fold