Modo compacto | Modo extendido

60 en 21 posts · 03-03-2015 23:30

Hola, alguien tiene el final de esta ultima fecha? o se acuerda un poco lo que tomaron... Dejaron los 5/10 min para verlo/irse ?

Muchas gracias!

501 en 217 posts · (04-03-2015)

Fijate en http://www.dds.com.ar en la parte de repositorio de examenenes que estan. Subieron el del 28 y el del 14 . Y el del 21 esta en un post.
y te daban 10 minutos para ver el ezexamen, y sino te ibas.

353 en 50 posts · 24-07-2015 21:59

viejo que tal? el del 21 de febrero del 2015 no lo encontre.. en un post de aca? de la pagina de dds.com ? dondeeeeee?
ajaja gracias!

EDIT: lo habia buscado como el orto mio.. aca esta el link por si les pasa http://www.utnianos.com.ar/foro/tema-apo...21-02-2015

6 en 6 posts · 17-01-2016 14:00

hola a todos,

alguno me puede dar una mano con el del 28/02/2015 ? hice el apartado de DER pero tengo problemas en la parte de objetos.
enunciado

el original usa un strategy. hasta ahí no hay dramas, pero despues dice:

Cita:Se desea que los costos por unidad de tiempo (diaria, semanal, mensual) ya no se especifiquen para cada auto sino para cada categoría. De esta forma, todos los autos de la categoría "económico" cuestan lo mismo. La decisión del tipo de facturación (diaria, mensual o semanal) sigue correspondiendo a cada auto.

lo que no entiendo es lo siguieten: en el diagrama original, un auto tiene muchas categorias. entonces, cual habria que tomar como referencia al momento de calcular el costo ? la primera ? la ultima ?
por ahí lo plantee mal o entendi cualquier cosa.

1.496 · (22-01-2016)

hola cuchodelosdecadentes !

No es muy claro como se hace el calculo, asi que como ellos primero hciieron un "calcularcosto(...)". Un mensaje que le llega a auto de alguna manera y no tenes idea como.
Yo supuse que de alguna forma ellos mismos te dicen que fecha quieren, la categoria que le corresponde al auto que queres alquilar y vos solo podrias usar calcularCosto(cat,..) osea de alguna forma le llega ese mensaje a auto, por ahi en el final preguntaría si interesa.

6 en 6 posts · 22-01-2016 01:24

hola CarooLina

yo tb habia planteado algo asi,



 

clase Categoria(unitarioDiario: Numero, unitarioSemanal: Numero, unitarioMensual: Numero) 

	metodo unitarioPorDia

		unitarioDiario

	fin

	

	metodo unitarioPorSemana

		unitarioSemanal

	fin

	

	metodo unitarioPorMes

		unitarioMensual

	fin





clase ModoDiario hereda ModoFacturacion

	metodo calcularCosto(categoria: Categoria, desde: Fecha, hasta: Fecha) 

		(self cantidadDeDias(desde,hasta)) * (categoria unitarioPorDia) 

	fin 



clase ModoSemanal hereda ModoFacturacion

	metodo calcularCosto(categoria: Categoria, desde, hasta) 

		(self cantidadDeSemanas(desde,hasta))*(categoria unitarioPorSemana) 

	fin





clase ModoMensual hereda ModoFacturacion

	metodo calcularCosto(categoria: Categoria, desde, hasta) 

		(self cantidadDeMeses(desde,hasta))*(categoria unitarioPorMes) 

	fin 



clase Auto(modo: ModoFacturacion) 

	atributo categorias 



	metodo perteneceA(categoria) 

		categoria contiene(categoria) 

	fin 



	metodo calcularCosto(categoria, desde, hasta) 

		if(! self perteneceA(categoria) ) 

			lanzar nueva Excepcion

		

		modo calcularCosto(categoria, desde, hasta)

	fin

Compilar y ejecutar código

pero me hace ruido que un auto tenga muchas categorias porque justamente eso te obliga a parametrizar la categoria.

igual para no hablar sobre el aire, mañana lo subo "semi resuelto" así criticamos entre todos los que se quieran sumar.
saludos y gracias !

edit: aclaro que esto que hice me parece feo, pero es lo que veo por el momento.

1.496 · 22-01-2016 11:56

A mi hay cosas del dominio que me dan dudas, que si me las responden por ahi haria otra cosa o no podria hacer nada jajaj blush

la idea de que categoria tenga esos tres atributos no me gusta, por que no es flexible. Cada vez que haya un nuevo modo de facturacion vas a tener que ir a toquetear la interfaz de categoria.
Yo directamente pense en Categoria(Descripcion, costo) y a la hora de crear las distiintas pense (por eso te digo que es algo dudoso del dominio)

ecoMensual = new Categoria("mensual mas barato", 50)
ecoSemanal = new Categoria("semanal mas barato", 60)
ecoDiario = new Categoria("diario mas barato", 70)

El auto en categoria, tendria todas esas y le agregas el plus (aunque no lo piden) de que una categoria no pueda ser alquilada de cierta manera. No use herencia por que todo lo que tienen es comun, entonces no valia la pena.

Si hubieras hecho esto por ahi seria mas simple meter tambien un templated method (no es que sea obligatorio pero como esta medio turbio por ahi compensa que se yo) La idea de patrones es ayudar, no perjudicarte.
Por que el costo es el mismo y vos tenes que calcular la cantidad de dias, semanas y meses... que si lo pensas algo en comun tienen? Te digo si vos para todo calculas la cantidad de dias, si lo dividis por (30) tenes los meses (esta ultima division la haces en mensual) y por 7 tenes las semanas. Aca si te das cuenta con un poco de mas laburo, pero para tratar de conseguir mas nota.. podes hacer esto. Como lo haces vos repetis codigo--> es mas simple y se lo puede criticar/favorecer blabla

6 en 6 posts · 23-01-2016 19:01

CarooLina

tenes razon en lo del metodo template, ni me fije en eso.

estuve viendo todo de nuevo, y me parece que hay un double dispatch, un template method, y un composite a medias en este final.

fijate que dice:

Cita:De esta forma, todos los autos de la categoría "económico" cuestan lo mismo

o sea que hay muchas categorias y hay muchos modos de facturacion. a su vez, cada categoria define el costo unitario para cada modo de facturacion independientemente de cada auto.

entiendo lo que estas haciendo, pero si haces para cada auto:

Cita:ecoMensual = new Categoria("mensual mas barato", 50)
ecoSemanal = new Categoria("semanal mas barato", 60)
ecoDiario = new Categoria("diario mas barato", 70)

me parece que estas definiendo el costo de cada categoria para cada auto.

adjunto lo que tengo hecho hasta ahora.
es para que opines/opinen, no lo planteo como solucion 100%

Punto1:

Spoiler: Mostrar

Punto2:

Spoiler: Mostrar

Codigo:

Spoiler: Mostrar



 



clase Auto 

	metodo calcularCosto(categoria, desde, hasta) 

		retornar modo.calcularCosto(categoria, desde, hasta) 

	fin







clase abstracta  Modo 	



	metodo final calcularCosto(categoria, desde, hasta)

		/* template method */  

		retornar self.periodos(desde, hasta) * self.costoUnitario(categoria)  

	fin



	metodo final costoUnitario(categoria)

		retornar categoria.unitarioPara(self) 

	fin 



	metodo abstracto periodos(desde, hasta) 

		/* lo implementa cada subclase */ 

	fin



	

clase ModoSimple hereda Modo



clase ModoDiario hereda ModoSimple

	redefinir periodos(desde, hasta) 

		retornar dias(desde, hasta) /*calcula dias entre dos fechas */

	fin 



clase ModoSemanal hereda ModoSimple

	redefinir periodos(desde, hasta) 

		retornar semanas(desde, hasta) /* calcula semanas entre dos fechas */ 

	fin 



clase ModoEstacional hereda Modo (

	atributo condicion: CondicionTemporada

	atributo modoDefault: ModoSimple

	atributo modoTemporada: ModoSimple



	metodo calcularCosto(categoria, desde, hasta) 

		if(condicion.check(desde,hasta)) 

			retornar modoTemporada.calcularCosto(categoria, desde, hasta) 

		

		retornar modoDefault.calcularCosto(categoria, desde, hasta) 

	fin



interface Categoria 

	/* define los costos unitarios para cada modo */

	/* double dispatch con Modo */  

	metodo unitarioPara(modo: ModoDiario) 

	metodo unitarioPara(modo: ModoSemanal) 

	metodo unitarioPara(modo: ModoMensual) 





clase Economico implementa Categoria 

	/* implementar */ 



clase NoTanEconomico implementa Categoria

	/* implementar */ 	





interface CondicionTemporada 

	metodo check(desde, hasta)

Compilar y ejecutar código

Notas:

Las desventajas que veo en esto, son las desventajas del double dispatch, ademas de que cada categoria tenga que ser un singleton.
Tambien se puede generalizar mas el composite que esta en el diagrama, pero no se si es necesario.
No veo la necesidad de interfaces entrates/salientes en este final.

1.496 · 24-01-2016 12:45

Cita:Estuve viendo todo de nuevo, y me parece que hay un double dispatch, un template method, y un composite a medias en este final.

Double dispatch nunca lo use como patrón ni mencione, se que esta en los apuntes. Por ahi vale la pena preguntarlo

Comoposite a medias, me suena muy raro como lo decis.Aunque el gamma menciona algo de un composite con restricciones tendria que volver a leerlo a ver de que trataba.

Cita:me parece que estas definiendo el costo de cada categoria para cada auto.

No! Por que es mas, podes decir que son singleton... (una vez que las creas nadie puede duplicarlas o volver a instanciar) y usas esas mismas para todos los autos.
Pensa que esto, cuando yo lo haga de esta manera va a estar justificado.

SOBRE el punto 1
En modo tenes que tener "id_modo" y el auto debe tener un "id_modo" como fk. Por que un auto tiene un modo (ya que es un strategy) y cada modo puede estar en varios autos. Por eso en auto con id_modo dejas en claro que modo le pertenece a ese auto.
Yo ademas hablaria de "id" mas que codigo, por ahi es solo un nombre.. pero es la costumbre de la cursada, todos hablan de id.
Y por ultimo, una persona se convierte en cliente por que tiene una reserva.. asi que para mi no va con "circulito" no me acuerdo si era cardinalidad o lo otro, va con palito... osea un cliente tiene una o muchas reservas.

Sobre el punto 2
Yo tambien use modo simple y le mande dos flechas desde estacional.
Y lo de las interfaces, que decis, creo que esta bien por que todo es nuesttro

6 en 6 posts · 24-01-2016 19:07

CarooLina

Cita:Comoposite a medias, me suena muy raro como lo decis.Aunque el gamma menciona algo de un composite con restricciones tendria que volver a leerlo a ver de que trataba.

claro, ni yo se que quise decir con lo de "a medias". vi que compartian una interface en comun pero como no era estrictamente el composite de libro, puse "a medias". en realidad, el ModoEstacional se compone de dos modos simples y nada mas. hay composicion, pero no es el "patron composite" propiamente dicho ( el de libro). esa seria la forma correcta de justificar. no hay "patron composite".

--------------------------------------

Cita:No! Por que es mas, podes decir que son singleton... (una vez que las creas nadie puede duplicarlas o volver a instanciar) y usas esas mismas para todos los autos.
Pensa que esto, cuando yo lo haga de esta manera va a estar justificado.

entiendo, pero si Categoria es singleton, entonces esto:

Cita:ecoMensual = new Categoria("mensual mas barato", 50)
ecoSemanal = new Categoria("semanal mas barato", 60)
ecoDiario = new Categoria("diario mas barato", 70)

no se podria hacer (justamente porque es singleton).

en java, por ejemplo, harias Categoria.INSTANCE, o Categoria.getInstance(), o cualquier otra implementacion del patron singleton en java. pero siempre habria una sola categoria, es decir, LA categoria. no podrias usar "new" muchas veces con la clase Categoria porque lo primero que harias es marcar el constructor como privado.

en todo caso, tendrias un repositorio de categorias donde vas agregando quitando/agregando objetos/entidades Categoria (identificadas con un string)

pero sigue habiendo un problema:

Cita:Se desea que los costos por unidad de tiempo (diaria, semanal, mensual) ya no se especifiquen para cada auto sino para cada categoría. De esta forma, todos los autos de la categoría "económico" cuestan lo mismo. La decisión del tipo de facturación (diaria, mensual o semanal) sigue correspondiendo a cada auto.

o sea que: a) hay muchas categorias, b) hay muchos modos de facturacion, c) cada auto sigue teniendo su unico modo de facturacion.

entonces cada categoria define el costo unitario por periodo, pero esto obviamente depende del modo de facturacion.
o sea:
la categoria economico define $5/dia para el modo de facturacion diario
la categoria economico define $8/semana para el modo de facturacion semanal
la categoria economico define $20/mes para el modo de facturacion mensual

y de ahi sale el double dispatch(me parece).

poner un atributo costoUnitario en cada categoria (como hice en la primera resolucion que puse), no puede ser una solucion.
eso es, porque en el diagrama original, el modo diario no tiene ningun atributo. o sea seria inventar un atributo. ademas de lo que dijiste vos en ese momento.

-----------------------------------------

aprovecho para preguntarte: alcanzaste a mirar este final ?

1.496 · 24-01-2016 22:13

uh tenes razon en eso del singleton, no lo pense jajaa se me ocurrio mientras te escribia y lo mande jaja.

mm no veo el problema, a mi me gusta lo que te puse en categoria y a menos que tengas una resolucion mejor, me gusta esa

Modo compacto \| Modo extendido Final diseño de sistemas 28/02/2015 RESUELTO
Autor	Mensaje