Hola compañeros, cómo están?

Los molesto para hacerles una consultita rápida:

El requerimiento es el siguiente: El nivel de concentración de los minions se calcula como la potencia de su arma más potente más su cantidad de bananas, en el caso de los amarillos. En los violetas, equivale sencillamente a su cantidad de bananas, aunque tengan armas.


Supongamos que la clase MINION (son soldaditos amarillos o violetas) tienen armas ( variable de instancia que hace referencia a una colección de ellas) y un tipo (variable de instancia que hace referencia a un tipo: amarillo o violeta). Al menos, yo lo pensé así.


Se desarrolla el siguiente método:

#MINION

>> nivelDeConcentración
^ tipo nivelDeConcentración: unMinion

>> armaMásPotente
(armas detectMax: [:unArma | unArma potencia) potencia . El detectMax me devuelve el objeto cuyo valor al evaluar el mensaje es el máximo. Al resultado de detectMax es correcto aplicar un mensaje como potencia??

#AMARILLO
>> nivelDeConcentración: unMinion
^ unMinion armaMásPotente + unMinion bananas.

#VIOLETA
>> nivelDeConcentración: unMinion
^ unMinion bananas.

Desde ya, mil gracias!!!
Saludos.

Hola!
Es correcto que el detectMax te devuelve el objeto que tiene la potencia máxima y que por eso después podés pedirle la potencia a ese objeto, lo único que opino es que está en el lugar incorrecto. Tu método se llama justamente arma más potente, con ese nombre se sobreentiende que lo que debería devolver es un arma entera, no una potencia como está haciendo ahora. Yo te recomendaría que eso lo hagas en el nivelDeConcentración de modo que te quede

#AMARILLO
>> nivelDeConcentración: unMinion
^ (unMinion armaMásPotente) potencia + unMinion bananas.

Es básicamente lo mismo, pero así el método hace lo que realmente pareciera que hace y lo podés usar en otros lados si hace falta (donde quizás no necesitás la potencia sino otro atributo o el arma en sí por ejemplo)

fijate que en los 2 casos depende de las bananas, osea en lc aclase minion podrias hacer algo como:

#MINION
>> nivelDeConcentración
^ (self bananas)+tipo nivelDeConcentración: unMinion.

Con respecto a armaMasPotente esta bien que devuelva el arma mas potente despues en la clase amarillo sacas su potencia.

bareel lo que hiciste funciona, pero es correcto lo que dijo Jess

si tu método es #armaMasPotente se espera que devuelva un arma, no una potencia.
por cierto, el selector del método (el nombre) no lo escribas con acepto: armaMásPotente lo mismo que #nivelDeConcentración
otra cosa, al método que pusiste ahí le falta el retorno (^).

lo que dijo Alexis es incorrecto. si bien ese código también funciona, el nivel de concentración depende del tipo, por lo tanto está bien que el dato de la cantidad de bananas lo use el tipo.
con lo que dijo alexis tenés algunos problemas:
1- tenés que hacer que el tipo VIOLETA devuelva cero para #nivelDeConcentración:
2- lo que el tipo devuelve no sería exactamente el nivel de concentración, sino un valor que debe ser operado con otro, para así obtener el nivel de concentración
3- si mañana tenés un MINION VERDE cuyo nivel de concentración no depende de las bananas, esa implementación ya no te sirve

---

 

| armas armaMasPotente |

armas := OrderedCollection with: 5 with: 9 with: 1 with: 3.

armaMasPotente := armas detectMax: [:unArma | unArma].

armaMasPotente printString

---

bareel una pregunta, ¿el método #detectMax: lo vas a implementar vos?

cuidado con lo siguiente (te tiro las pistas para que le prestes atención):
¿qué pasa si la colección está vacía?
¿qué pasa si no hay solo un máximo?

Fíjate como estas pensando la solución
Le estas pasando a un objeto "color", atributo de unMinion cualquiera, como parametro otro minion cualquiera, que ni siquiera esta definido en el mensaje " nivel de concentración" del minion al que le envías el mensaje
No hay forma que funcione así, a lo sumo debes pasarle self, pero tampoco es una solución correcta, porque podrías mandarle un mensaje por ejemplo
MinionAmarillo tipo niveldeconcentracion: unminionvioleta y te lo resolvería
Lo que deberias hacer es crear una subclase de minion por cada color, y que cada una resuelva su propio "nivel de concentración", sin depender de un atributo color que lo resuelva

es verdad lo que dice odin , no me había dado cuenta.

sería algo así:

#MINION

>> nivelDeConcentración
^ tipo nivelDeConcentración: self

esa implementación sirve. la otra propuesta de odin también es válida, o sea subclasificar los minions.
y acá ya no hay un manual a seguir, sino que depende de una estrategia de diseño. cuándo conviene o no subclasificar es una cuestión filosófica, y en tu caso va a depender del gusto del ayudante o docente que te vaya a corregir (salvo que seas un crack y puedas justificar muy bien tu elección).

(17-11-2014 21:12)LeaTex escribió:  bareel lo que hiciste funciona, pero es correcto lo que dijo Jess

si tu método es #armaMasPotente se espera que devuelva un arma, no una potencia.
por cierto, el selector del método (el nombre) no lo escribas con acepto: armaMásPotente lo mismo que #nivelDeConcentración
otra cosa, al método que pusiste ahí le falta el retorno (^).

lo que dijo Alexis es incorrecto. si bien ese código también funciona, el nivel de concentración depende del tipo, por lo tanto está bien que el dato de la cantidad de bananas lo use el tipo.
con lo que dijo alexis tenés algunos problemas:
1- tenés que hacer que el tipo VIOLETA devuelva cero para #nivelDeConcentración:
2- lo que el tipo devuelve no sería exactamente el nivel de concentración, sino un valor que debe ser operado con otro, para así obtener el nivel de concentración
3- si mañana tenés un MINION VERDE cuyo nivel de concentración no depende de las bananas, esa implementación ya no te sirve

---

 

| armas armaMasPotente |

armas := OrderedCollection with: 5 with: 9 with: 1 with: 3.

armaMasPotente := armas detectMax: [:unArma | unArma].

armaMasPotente printString

Compilar y ejecutar código

---

bareel una pregunta, ¿el método #detectMax: lo vas a implementar vos?

cuidado con lo siguiente (te tiro las pistas para que le prestes atención):
¿qué pasa si la colección está vacía?
¿qué pasa si no hay solo un máximo?

LeaTex hay dos tipos de enfoques: optimizar los recursos necesarios o esperar que algun dia se le vaya a agregar otro modulo al programa y hacer los cambios necesarios para que este se pueda reutilizar facilmente.

No estoy diciendo que vos tengas razon o que yo la tenga, solo estoy diciendo que es erroneo marcar una como erronea, depende solo del programador y de lo que necesite.

Ahora si vos sabes que no se le va a agregar ningun minion (que se puede suponer a menos que te lo pida el enunciado) entonces estas repitiendo codigo porque hay comportamientos comunes que se pueden unificar en minion.

Con respecto al pto 2 podrias ponerle otro nombre al metodo y ya no estaria retornando la concentracion.

Si, la idea es mantener la comprensión de la solución y el encapsulamiento y abstracción del paradigma, tambien la rehusabilidad de la solucion, mas allá de la funcionalidad de la solución, en este caso, si luego hay más diferencias y métodos nuevos que resolver, (que seguramente los habrá) se pierde de vista la solución, y el objeto minion pasa a un segundo plano, con todo el código en un atributo "color", cuando color se supone es un tipo de minion por como esta planteado el problema originalmente
Y si, es todo un tema a veces diseñar quien debería resolver el mensaje y que debe hacer cada objeto

(17-11-2014 21:56)alexis caspell escribió:  LeaTex hay dos tipos de enfoques: optimizar los recursos necesarios o esperar que algun dia se le vaya a agregar otro modulo al programa y hacer los cambios necesarios para que este se pueda reutilizar facilmente.

No estoy diciendo que vos tengas razon o que yo la tenga, solo estoy diciendo que es erroneo marcar una como erronea, depende solo del programador y de lo que necesite.

Ahora si vos sabes que no se le va a agregar ningun minion (que se puede suponer a menos que te lo pida el enunciado) entonces estas repitiendo codigo porque hay comportamientos comunes que se pueden unificar en minion.

Con respecto al pto 2 podrias ponerle otro nombre al metodo y ya no estaria retornando la concentracion.

bueno, yo SÍ estoy diciendo que tu solución es errónea, aunque funcione.
también podemos meter todo hardcodeado en un solo método con 200 condicionales IF y a la mierda. pero no es el objetivo de la materia (ni el sentido del paradigma).

cuando estás en un laburo y tenés que entregar un ejecutable hoy (porque la fecha real de entrega era ayer), ahí mandá toda la fruta que quieras.
si estás cursando paradigmas y me hacés eso, te lo pongo como mal sin derecho a réplica.

¿es correcto que un minion conozca su nivel de concentración? ¿es correcto que el tipo de minion sepa cómo calcular el nivel? ¿por qué no tenemos un objeto "calculador de nivel de concentración" que lo resuelva? y que ese calculador a su vez colabore con otro "estrategia de cálculo de nivel de concentración" que sea quien dice cómo se calcula para cada tipo de minion. ¿vale la pena tener todos esos objetos para hacer algo tan sencillo como sacar un máximo y sumar?

Claro, ahí se me aclararon un poco las cosas.

Yo pensé que no era correcto escribir, por ejemplo,

#Amarillo
>>nivelDeConcentración
^ *** (self ArmaMasPotente) potencia *** + self bananas


La otra duda que me acaba de surgir es la siguiente:

Cuando yo defino e implemento un método como nivelDeConcentración, mi intención fue pasarle el Minion que justamente hace referencia a ese determinado tipo amarillo (es decir, self tal como dicen ustedes). Pero, cuando yo defino el método no tengo que pasarle parámetros que sean "generales"???

Es por eso que yo lo declaré de esta manera: nivelDeConcentracion: unMinion y no puse nivelDeConcentración: self (justamente, porque pensé que esto iba en el workspace).

Me podrían aclarar esta cuestión?

Muchísimas gracias!!!

El nivel de concentración de los minions se calcula como la potencia de su arma más potente más su cantidad de bananas, en el caso de los amarillos. En los violetas, equivale sencillamente a su cantidad de bananas, aunque tengan armas.


Como yo lo resolvería:

 #Minion>> nivelDeConcentracion

   ^ self tipo nivelDeConcentracion:self





#Amarillo>> nivelDeConcentracion: unMinion

  ^ unMinion armaMasPotente potencia + unMinion incrementoDeConcentracionPorBananas



#Violeta>> nivelDeConcentracion: unMinion

  ^unMinion incrementoDeConcentracionPorBananas





#Minion>> incrementoDeConcentracionPorBananas

  ^ bananas size

Por qué?
1) El nivel de concentracion claramente depende del tipo.
2) No hay código repetido. El "código repetido" no es escribir 2 veces lo mismo, sino tener patrones de colaboración entre objetos duplicados. En este caso, los minions violetas saben el nivel de concentración por las bananas. Los amarillos también. Se podría armar una jerarquía de tipos para escribir una sola vez "incrementoDeConcentracionPorBananas", pero eventualmente terminaría o llamando a super o agregando un ^0 para mantener el polimorfismo. Hay que mantenerlo simple, y esta es una forma elegante (KISS).
3) Composición > Herencia.

Ahora bien. Está mal hacer lo que plantea alexis? Y, yo diría que no. En principio no van a venir mas minions (YAGNI), asique está bien. Sin embargo, con la alternativa que propongo (que segun entiendo es igual que la de LeaTex) gano un poco mas de flexibilidad y no pierdo nada.

(18-11-2014 15:47)bareel escribió:  Claro, ahí se me aclararon un poco las cosas.

Yo pensé que no era correcto escribir, por ejemplo,

#Amarillo
>>nivelDeConcentración
^ *** (self ArmaMasPotente) potencia *** + self bananas


La otra duda que me acaba de surgir es la siguiente:

Cuando yo defino e implemento un método como nivelDeConcentración, mi intención fue pasarle el Minion que justamente hace referencia a ese determinado tipo amarillo (es decir, self tal como dicen ustedes). Pero, cuando yo defino el método no tengo que pasarle parámetros que sean "generales"???

Es por eso que yo lo declaré de esta manera: nivelDeConcentracion: unMinion y no puse nivelDeConcentración: self (justamente, porque pensé que esto iba en el workspace).

Me podrían aclarar esta cuestión?

Muchísimas gracias!!!

a ver, creo que estas confundiendo mucho las cosas, como esta planteado en tu solucion principal, tenes
miniones, con atributos, un atributo es un tipo, que puede ser de clase Amarillo o Violeta
Amarillo o Violeta, no son miniones, no conocen los demas atributos del minion, de hecho, cuando los instancies, será algo asi
amarillo:= Amarillo New
y
minionAmarillo1 tipo: amarillo
minionAmarillo2 tipo: amarillo
el objeto amarillo es el mismo para ambos miniones (salvo que crees "amarillo1", "amarillo2", etc. lo que no tendria demasiado sentido)


por eso no podes usar
#Amarillo
>>nivelDeConcentración
^ *** (self ArmaMasPotente) potencia *** + self bananas

esos son atributos del minion, no de amarillo, y no hay forma de que amarillo sepa a que minion debe evaluar, salvo que se lo pase por parametro el minion que invoca el mensaje

ahora imaginá que en el futuro hay mas diferencias en los miniones, que, por ejemplo, el minion amarillo, tenga una mochila con herramientas varias, y el violeta no
se te complicaría demasiado así, porque cada minion amarillo, tendria una mochila diferente, ademas los violetas no la tienen, y un solo objeto amarillo no podria resolverlo para todos, tampoco se podria asignar, como atributo, una mochila a todos los miniones, porque los violetas no la tienen
deberas hacer una instancia diferente de amarillo por cada minion de ese color
¿se entiende?
siempre debes pensar en una solucion mas general y practica, y una que se pueda modificar facilmente si cambian las condiciones y parametros

Saludos

(20-11-2014 21:53)odin escribió:  a ver, creo que estas confundiendo mucho las cosas, como esta planteado en tu solucion principal, tenes
miniones, con atributos, un atributo es un tipo, que puede ser de clase Amarillo o Violeta
Amarillo o Violeta, no son miniones, no conocen los demas atributos del minion, de hecho, cuando los instancies, será algo asi
amarillo:= Amarillo New
y
minionAmarillo1 tipo: amarillo
minionAmarillo2 tipo: amarillo
el objeto amarillo es el mismo para ambos miniones (salvo que crees "amarillo1", "amarillo2", etc. lo que no tendria demasiado sentido)

¿Para qué va a crear ese amarillo? Es innecesario y de hecho está mal por lo que pide el enunciado porque vos no le podés asignar el color al minion, eso se tiene que hacer solo cuando se crea, y la única forma de que cambie a violeta es tomando el suero mutante, tampoco podés meter eso a mano. Con hacer en el initialize del Minion un self tipo: Amarillo new basta y después cuando toma el suero te ocupás de que cada color sepa a qué otro color debe cambiar.

(21-11-2014 01:02)Jess escribió:  

(20-11-2014 21:53)odin escribió:  a ver, creo que estas confundiendo mucho las cosas, como esta planteado en tu solucion principal, tenes
miniones, con atributos, un atributo es un tipo, que puede ser de clase Amarillo o Violeta
Amarillo o Violeta, no son miniones, no conocen los demas atributos del minion, de hecho, cuando los instancies, será algo asi
amarillo:= Amarillo New
y
minionAmarillo1 tipo: amarillo
minionAmarillo2 tipo: amarillo
el objeto amarillo es el mismo para ambos miniones (salvo que crees "amarillo1", "amarillo2", etc. lo que no tendria demasiado sentido)

¿Para qué va a crear ese amarillo? Es innecesario y de hecho está mal por lo que pide el enunciado porque vos no le podés asignar el color al minion, eso se tiene que hacer solo cuando se crea, y la única forma de que cambie a violeta es tomando el suero mutante, tampoco podés meter eso a mano. Con hacer en el initialize del Minion un self tipo: Amarillo new basta y después cuando toma el suero te ocupás de que cada color sepa a qué otro color debe cambiar.

No podes inicializar el minion con Amarillo, porque hay miniones violetas, si o si debes pasarlo como parametro y poner un if, o asignarlo después en el workspace
A lo que voy es que surgen todas estas complicaciones y limitaciones con la solución planteada como está, cuando con una subclase por cada tipo de minion, me parece, es mas simple y comprensible para resolver
Igual, como dicen es un tema de diseño y algo muy personal eso, no es que no funcione bien haciendo todo eso y agregando todo ese código

Tenes el enunciado completo ?

Porque para lo que leo no entiendo porque tenes el tipo de minion como un atributo. Siendo que un minion es Amarrillo o Violeta.

Clase Minion (clase abstracta)
Atributos:
-Armas
-Bananas
Metodos:
-nivelDeConcentracion (metodo abstracto, responsabilidad de las subclase de implementar)

Clase Arma
Atributo
-potencia

Clase MinionAmarillo
-armaMasPotente
-nivelDeConcentracion (retorna (armaMasPotente potencia)+bananas)

Clase MinionVioleta
-nivelDeConcentracion (retorna bananas)


Sorry que no esta en smalltalk, hace un par de años que la curse, te lo podría escribir en java sino.