[Php-objetos] Juan Re: Entrega ejercicio 3.1

Juan Marcos Rigoli deimos.codes en gmail.com
Jue Mar 5 15:49:46 ARST 2009


Hola Leo!

El día 5 de marzo de 2009 2:27, Leonardo Tadei - Pegasus Tech Supply
<leonardot en pegasusnet.com.ar> escribió:
> Hola Juan,
>
> El mar, 03-03-2009 a las 12:33 -0300, Juan Marcos Rigoli escribió:
>> Se que lo vimos en clase, pero no lo quise anotar para ver si podia
>> hacerlo solo.
>
>        Lo hubieras anotado...
>
>

Ouch!!

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>        Es chiste!!!
>        Perdón, no me pude aguantar!

Te la dejé picando jeje

>
>>  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.

>>  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, 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?

>        Si Pagos está adentro de Asociados, es solo el pago de _una_ instancia
> de Asociado, así que por definición "sabe" esto.
>
>        Hacés lo mismo con los préstamos.
>
>        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. O sería mas correcto hacer Asociado abstracto y que
AsociadoRegular y AsociadoEspecial ambos que hereden de Asociado?
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.

>
>> Por cierto te
>> mandé la lista de requerimientos ayer a la noche, te llegó?
>
>        Arranqué la semana con mucha cosa y me fui poniendo al día de a poco...
> me parece que ya te lo respondí.
>

Sisi, me la respondiste, pero este te lo habia mandado antes que me
respondas lo de los requerimientos (que para variar malentendí un poco
los conceptos).

>> Saludos!
>
>        =mente!

Saludos!

- Juan Marcos.

> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> http://blog.pegasusnet.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-objetos mailing list
> Php-objetos en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-objetos
>


Más información sobre la lista de distribución Php-objetos