20-07-2015, 12:05
Link del final:
https://docs.google.com/document/d/1czeo...oilgRs/pub
Resolución:
A)1)
Ver Diagrama de Clases.png
EDITO: Está mal el diagrama, por un error de copypaste repetí una clase, la cual yo llame ConNiebla
[attachment=11287]
#Día
>> temperaturaBase
^(tRef * 1.15 + tMod sqrt)/ tInf.
>>temperatura
^tipo temperatura: (self temperaturaBase).
#Nublado
>>temperatura: base
^base*cantNubes.
#Normal
>>temperatura: base
^base.
#ConNiebla
>>temperatura:base
^base – cantNiebla.
#Mes
>> temperaturaPromedio
^(días sum: [:dia | dia temperatura]) / (días size).
La solución aquí propuesta es mejor en términos de polimorfismo al crear nuevas clases para los tipos de días, delegando de esta manera el cálculo de la temperatura a cada tipo de día. Esto permite un mayor encapsulamiento para el cálculo de la temperatura.
2) En un principio si, ya que permite delegar el cálculo de la temperatura en cada uno de los tipos de día, aumentando así la declaratividad de la solución. En el caso que yo propuse la solución es mejorada utilizando composición, ya que, de esa manera, un día puede pasar de estar normal a estar nublado.
3) La solución propuesta por el ejercicio tiene poca declaratividad ya que (por ejemplo, en el caso de temperaturaPromedio) el código muestra más COMO se realiza el cálculo. En la solución que propuse yo, es más fácil entender QUE es lo que se quiere obtener simplificando el código en una sola línea. A nivel expresividad, la solución propuesta por el ejercicio utiliza términos como tot, cant, d, entre otros, que restan expresividad en la solución. Esos términos son eliminados en la nueva propuesta ya que no son necesarios y se ve mejorada la expresividad con términos más claros.
4) Si, lo permite.
nublado := Nublado new.
nublado inicializar.
unDia tipo:nublado.
B)1) primerMayorQue valor criterio = (>valor).head.filter criterio
f = primerMayorQue 40 even
g = primerMayorQue 38.5 elevada
h = primerMayorQue “perez” ((==’s’).last)
2) El concepto es orden superior. Al utilizar una función de orden superior como primerMayorQue (que utiliza las funciones como head, filter y (>)), se permite evitar la lógica repetida, simplificando la solución y delegando la lógica en una única función.
3) Se realizó directamente en el punto 1.
C)1) Deben existir los siguientes predicados en la base de conocimientos:
- trabajaPara/2: Debe ser inversible respecto de la Persona.
- esMafioso/1.
- encargo/3: Debe ser inversible respecto de la Persona.
- pareja/2.
- personaje/2.
2) Si, ya que se utiliza un mismo predicado para tratar los distintos tipos de encargos. De esta manera, si se agregan más encargos, no es necesario generar nuevos predicados para tratarlos.
3) Si, es posible.
cuidador(Personaje):-
encargo(_,Personaje,_),
forall(encargo(_,Personaje,Encargo), Encargo = cuidar(_)).
Cualquier duda pregunten!!
https://docs.google.com/document/d/1czeo...oilgRs/pub
Resolución:
A)1)
Ver Diagrama de Clases.png
EDITO: Está mal el diagrama, por un error de copypaste repetí una clase, la cual yo llame ConNiebla
[attachment=11287]
#Día
>> temperaturaBase
^(tRef * 1.15 + tMod sqrt)/ tInf.
>>temperatura
^tipo temperatura: (self temperaturaBase).
#Nublado
>>temperatura: base
^base*cantNubes.
#Normal
>>temperatura: base
^base.
#ConNiebla
>>temperatura:base
^base – cantNiebla.
#Mes
>> temperaturaPromedio
^(días sum: [:dia | dia temperatura]) / (días size).
La solución aquí propuesta es mejor en términos de polimorfismo al crear nuevas clases para los tipos de días, delegando de esta manera el cálculo de la temperatura a cada tipo de día. Esto permite un mayor encapsulamiento para el cálculo de la temperatura.
2) En un principio si, ya que permite delegar el cálculo de la temperatura en cada uno de los tipos de día, aumentando así la declaratividad de la solución. En el caso que yo propuse la solución es mejorada utilizando composición, ya que, de esa manera, un día puede pasar de estar normal a estar nublado.
3) La solución propuesta por el ejercicio tiene poca declaratividad ya que (por ejemplo, en el caso de temperaturaPromedio) el código muestra más COMO se realiza el cálculo. En la solución que propuse yo, es más fácil entender QUE es lo que se quiere obtener simplificando el código en una sola línea. A nivel expresividad, la solución propuesta por el ejercicio utiliza términos como tot, cant, d, entre otros, que restan expresividad en la solución. Esos términos son eliminados en la nueva propuesta ya que no son necesarios y se ve mejorada la expresividad con términos más claros.
4) Si, lo permite.
nublado := Nublado new.
nublado inicializar.
unDia tipo:nublado.
B)1) primerMayorQue valor criterio = (>valor).head.filter criterio
f = primerMayorQue 40 even
g = primerMayorQue 38.5 elevada
h = primerMayorQue “perez” ((==’s’).last)
2) El concepto es orden superior. Al utilizar una función de orden superior como primerMayorQue (que utiliza las funciones como head, filter y (>)), se permite evitar la lógica repetida, simplificando la solución y delegando la lógica en una única función.
3) Se realizó directamente en el punto 1.
C)1) Deben existir los siguientes predicados en la base de conocimientos:
- trabajaPara/2: Debe ser inversible respecto de la Persona.
- esMafioso/1.
- encargo/3: Debe ser inversible respecto de la Persona.
- pareja/2.
- personaje/2.
2) Si, ya que se utiliza un mismo predicado para tratar los distintos tipos de encargos. De esta manera, si se agregan más encargos, no es necesario generar nuevos predicados para tratarlos.
3) Si, es posible.
cuidador(Personaje):-
encargo(_,Personaje,_),
forall(encargo(_,Personaje,Encargo), Encargo = cuidar(_)).
Cualquier duda pregunten!!
.gif "=)")
