[Php-objetos] Juan Re: Entrega ejercicio 3.1

[Leonardo Tadei - Pegasus Tech Supply]

Hola Juan,

El jue, 05-03-2009 a las 14:49 -0300, Juan Marcos Rigoli escribió:
> >>  Una de las diferencias con lo que me acuerso es que yo
> >> modelé los pagos.
> >
> >        Sí, no le veo mucho sentido para este enunciado...
> >        Además, modelaste el Pago, no los PagoS. Tenés una cardinalidad 0 - 1.
> > Tampoco le veo el sentido, si son los Pagos, que sean una agregación.
> >
> 
> A veces lo de plural se me confunde, deberia hacer una clase Pagos que
> tenga una relación de Composición con una clase Pago.

	Tal vez sí, y la clase Pagos sería solo una colección de objetos Pago.
	Obvio que no hace falta modelar la clase, ya que basta un atributo
Pagos que sea una colección de Objetos Pago

> >>  Se que no va a estar bien de una, pero quiero
> >> ponerme práctico para cuando tenga que hacer la tesis.
> >
> >        Tenés unas cosas sin sentido. Por ejemplo hacés
> >
> > public function puedeRetirar() {
> >        if (! $this->pagos->cuotaAlDia($this->idAsociado))
> >                return false;
> > ...
> >
> >        Pero si tenés como atributo interno a los pagos, no tiene sentido
> > pasarle al método como atributo el ID del Asociado!
> 
> El tema es que se me confunde un poco, la biblioteca tiene que tener
> una lista de todos los pagos, y el asociado tendria que tener una
> lista de pagos relacionado con el usuario,

	Mmmm... si bien se puede modelar de varias maneras, hay cosas que se
cancelan. Si la Biblioteca tiene una colección de Asociados, y los
Asociados tienen una colección de Pagos, no hace falta poner un acceso a
los Pagos modelado en la Biblioteca, porque ya los tiene vía los
Asociados.
	También podrías modelar que la Biblioteca tiene una colección de
Asociados y otra de PagosDeAsociados, pero en ese caso el Asociado no
tiene sus pagos, sino que los tiene la Biblioteca.
	Tener dos veces los Pagos seguro que no está bien!


>  pero entro un poco en
> conflicto con eso, en alguna parte del programa deberia hacer:
> 
> $pago = new Pago($guita, $usuario [, mes]); // $usuario por agregación
> 
> $usuario->addPago($pago);
> $banco->addPago($pago);
> // Ambos por agregación
> 
> esto esta bien asi?

	No, porque repetís sin sentido los Pagos...

> >        Tenés mal varias asociaciones... revisá cuando es rombo vacío y cuando
> > es lleno, y qué sentido tiene en este modelo.
> >        También revisá las cardinalidades: según tu gráfico un asociado puede
> > no tener un tipo de asociado, lo cual no tiene sentido...
> 
> El asociado tiene que tener un tipo, pero habiamos hablado de
> asociarlo para que si en algun momento un tipo de usuario modifica la
> restricción de líbros, todos los asociados que sean de ese tipo se
> modificarían.

	Es correcto.

>  O sería mas correcto hacer Asociado abstracto y que
> AsociadoRegular y AsociadoEspecial ambos que hereden de Asociado?

	Esto es un detalle de implementación. De hecho yo hubiera abstraido
tanto al Asociado como al Tipo!

> Porque si bien en ambos la diferencia es la cantidad de libros que
> pueden retirar, dice que el diseño tiene que contemplar nuevos tipos
> de asociados que pueden tener restricciones distintas.

	Efectivamente, una forma simple de agregar funcionalidad es agregar
nuevas subclases y que el que las usa, se refiera a la superclase.


	Seguimos!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key