[Php-objetos] Juan Re: Entrega ejercicio 2.3

Juan Marcos Rigoli deimos.codes en gmail.com
Jue Mar 5 14:10:19 ARST 2009


Hola leo!

El día 5 de marzo de 2009 2:03, Leonardo Tadei - Pegasus Tech Supply
<leonardot en pegasusnet.com.ar> escribió:
> Hola Juan,
>
> El mar, 03-03-2009 a las 10:35 -0300, Juan Marcos Rigoli escribió:
>> Aca vá, espero que este bien encaminado jeje. Saludos!
>
>        Vas bien encaminado.
>        Para mi gusto, estás implementando algunas cosas no pedidas, y esto
> siempre es un arma de doble filo...
>
>        No me parece correcta esta generalización:
> - Para limitar las extracciones de $100 diarios de las cuentas
> universitarias un método puede
> **        ser llevar un registro de los movimientos de las transacciones de
> la cuenta, al igual que en
> **        el caso del límite de extracciones mensuales. Como ésto es
> fundamental para el control de
> **        cualquier cuenta bancaria, se implementó en todas las cuentas.
>
>        No es cierto que esto sea fundamental para todas las cuentas bancarias!
> Las Cuentas Corrientes no lo tienen.

Yo tengo una cuenta corriente en el banco y puedo hacer que me de un
listado de los ultimos movimientos. A lo que me refiero de fundamental
es que en la mayoría de los casos que conozco de manejo de dinero es
importante tener registrados los movimientos para llevar un control y
ver cómo se llegó a eso.

>        Fijate que esto te fuerza a poner una semántica ficticia "Si el límite
> de extracciones mensuales de Cuenta Corriente es 0, no se limita la
> cantidad." y cómo se hace en tu sistema para tener una Cuenta Corriente
> con un descubierto pactado de Cero??? Es un caso muy común: te dan una
> Cta Cte para librar cheques, etc, pero no te dan descubierto.

En realidad mezclé yo las palabras en el comentario y se arrastró mal
(y lo corregí). El límite 0 de cantidad de extracciones es de una Caja
de Ahorro y no me pareció mal, ya que limitar a 0 extracciones por mes
haria que en ningún momento puedas retirar dinero, y eso no debería
pasar así, ya que para que no se pueda retirar se debería implementar
que se puedan deshabilitar las cuentas. Lo que sí esta mal y no me di
cuenta es que una Caja de Ahorro pueda no tener giro en descubierto,
en ese caso voy a modificar el código y poner que si el límite es -1
no tenga límite la cuenta, ya que un límite negativo no tiene sentido.

>
>        Esto ya lo hablamos, pero el manejo de los movimientos es más de lo que
> pide el ejercicio, pero por separado para depósitos y extracciones es
> complicado y no aporta nada que yo vea.
>

Es verdad que el manejo por separado de las extracciones y los
depósitos no tienen sentido, lo hice así sin haber una razón, pero
tampoco habia un motivo que me diga que no tenia que hacerlo asi. Si
no queda mal, uniría extraciones y depósitos haciendo que las
extracciones tengan valores negativos y los depósitos valores
negativos.

¿Por qué insisto con modelar los movimientos? Porque me puse a pensar
en cómo llevar la cuenta por mes y por dia y el modelar los
movimientos me permiten hacer una cuenta por algo histórico en lugar
de llevar la cuenta del mes o el dia y desecharlo si el dia cambia. Se
que agregar cosas es un arma de doble filo, pero yo no estoy agregando
funcionalidad al ejercicio ni haciendo que haga más cosas de lo que
pide, modelar los movimientos sólo es una forma de resolverlo. Es
verdad que hay formas de hacerlo sin modelar los movimientos, pero en
el ejercicio no dice en ningun lugar que hay que modelarlos, pero
tampoco dice que NO hay que hacerlo. Modelé los movimientos también
por que esto permitiría hacer estadísticas y otras cosas pensando en
que el sistema podia en algún momento expandir su funcionalidad y me
pareció coherente. Insisto, no hace mas de lo que pide, sólo lo
resuelve de esa forma, en ningun lado dice como hacerlo.

>        O el revoleo que hacés con la hora de verano no tiene sentido, y me
> hace falta esa explicación que prometés.
>        Me parece que en persona en vez de por acá: me aguanto hasta el
> Sábado. ;-)

Si, es medio un enrosque, te lo explico el sábado.

>
>        Esta implementación va a contramano de lo legible:
> public function extraer($importe) {
>        parent::extraer($importe);
>
>        if (($this->limiteDescubierto != 0) && (abs($this->saldo - $importe) >
> $this->limiteDescubierto))
>                throw new Exception("El retiro excede el límite del giro en
> descubierto de la cuenta.");
>
>        $this->saldo -= $importe;
>        $this->extracciones->addMov($importe);
> }
>
>        Uno primero valida y después llama al método heredado!!!
>        En tu caso el metodo heredado solo tiene un validación, y la
> implementación es correcta, pero leer esto hace pensar que primero hacés
> la cosa general, después validás, y después decidís si hacés la cosa
> particular o no... parece incoherente.
>        Para agrupar ese comportamiento creá un método "validarExtracción() y
> usalo para hacer la validación.

Lo hice así porque en las 3 clases voy a tener la misma comparación
con la misma excepción y el mismo mensaje al principio. Hacer una
función para eso sólamente no me parece necesario, voy a hacer mejor
el método extraer() abstracto y meto lo de mayor que cero dentro de la
implementación de las clases, o hacer validarExtraccion() en las
subclases e implementar extraer() en la superclase, ya que lo que
cambia es la validación de la extraccion, no la extracción en si.

>
>        Nos vemos!
>

Salute!

- 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