Re: [Python-es] Un problema de herencia múltiple.

[Pavel Muñoz]

ok... ya lei tu explicacion, entiendo el problema.... ahora dame tiempo de
revisar tu codigo

2008/1/14 José Miguel Sánchez Alés <aussiliar en online.fr>:

> (Redirecciono a la lista de nuevo)
>
> El Mon, 14 de Jan de 2008, a las 03:46:45PM -0600, Pavel Muñoz dijo:
>
> > Podiras decirnos un poco mas directamente, cual es el objetivo de todo
> > esto?... pregunto esto porque me parece que deberiamos hacer un pequeno
> > rediseno de tus clases y quiero saber que es exactamente lo que esperas
> que
> > hagan.
>
> Por supuesto lo explico mejor e, incluso, os dejo el enlace[1] al módulo
> por
> si lo queréis ver/aprovechar.
>
> El módulo pretende calcular hipotecas, en concreto, cada cuota mensual y
> cada deuda (es decir, el dinero que aún queda por pagar al banco).
>
> Existen varios tipos de hipotecas (de cuotas constantes, de
> amortizaciones constantes, de cuota con crecimiento geométrico, etc.).
> Deduje las fórmulas hipotecarias de cada tipo y llegué a la conclusión
> de que deuda y cuota se podían reducir a una misma fórmula para todos
> los tipos, que dependían de dos parámetros que llamé K__ y Z__,
> característicos de cada tipo de hipoteca.
>
> Así pues definí las siguientes clases:
>
> * PatronHipoteca (que es la clase A de mi post) y que implementa los
>  métodos cuota y deuda comunes para todas las hipotecas.
>
> * SistemaFrances (cuotas constantes), QuotaCreGeo y QuotaCreAri cuya
>  clase antecesora es PatronHipoteca y que definen los parámetros K__ y
>  Z__.  Estas clases son las B de mi anterior post y que yo reduje a dos
>  porque como verás más adelante el sistema francés no me da problemas.
>
> * SistemaAleman (amortizaciones constantes), que me di cuenta viendo
>  las fórmulas que me habían salido que era un caso particular de
>  QuotaCreA. Así pues SistemaAlemán hereda de QuotaCreAri.
>
> Hasta aquí todo bien. Estos son los tipos teóricos de hipotecas. El
> problema es la práctica bancaria.
>
> Los bancos no usan los tipos teóricos puros. Y me explico. Por ejemplo,
> QuotaCreGeo implementa una hipoteca con cuotas de crecimiento
> geométrico, es decir, si el primer mes la cuota es Q, el segundo es a*Q,
> el tercero a^2*Q y así sucesivamente. Sin embargo, los bancos no hacen
> eso. Los bancos mantienen durante un año (doce mensualidades) constante
> la cuota mensual Q. A continuación, multiplican por la razón "a" y
> vuelven a mantener durante un año la cuota mensual a*Q y así
> sucesivamente. Lo mismo es aplicable a la QuotaCreAri con la salvedad de
> que el crecimiento es aritmético y no geométrico.
>
> El caso es que matemáticamente puedo resolver esto fácilmente: calculo
> cuotas y deudas anuales, no mensuales, con los tipos teóricos de
> hipoteca que ya he implementado y luego fracciono las cuotas (que no
> consiste simplemente en dividir la cuota entre 12, dicho sea de paso).
> Este "fraccionamiento" de la cuota es independiente de cuál sea la ley
> de crecimiento de las cuotas (el tipo de hipoteca en otras palabras);
> siempre se hace de la misma forma.
>
> Sabiendo esto definí las siguientes clases:
>
> * QuotaMixta que es la clase que se encarga del fraccionamiento, digamos
>  que de pasar las cuotas y deudas anuales calculadas con las clases del
>  nivel B a cuotas y deudas mensuales.  Es la clase que yo denominé C.
>
> * AmorCte, QuotaCte, QuotaCre, QuotaCreA y AmorCteAn son las clases que
>  implementan los tipos "prácticos" de hipotecas de los cuales:
>  - AmorCte hace amortizaciones constantes mensuales, así que no hay que
>    hacer ningún fraccionamiento de la cuota y se basa directamente en
>    SistemaAleman.
>  - QuotaCte implementa la hipoteca de cuotas constantes. Podría hacer
>    uso de QuotaMixta, pero no es necesario ya que da lo mismo hacer
>    constante la cuota anual y luego hacer un fraccionamiento para
>    calcular las cuotas mensuales, que directamente hacer constantes las
>    cuotas mensuales. Así que se basa en SistemaFrances y tampoco da
>    problemas.
>  - QuotaCre, QuotaCreA y AmorCteAn son los equivalentes reales a
>    QuotaCreGeo, QuotaCreAri y SistemaAleman, respectivamente. Así pues
>    necesitan hacer uso de los métodos de fraccionamiento de QuotaMixta.
>  Estas son mi nivel D, en el que como ves algunas hacen uso del nivel C
>  (QuotaMixta).
>
> Así que me queda el siguiente esquema:
>
>                cuota               cuota
> QuotaCre,... <---------- QuoMixta <------- QuotaCreGeo,... +
> PatronHipoteca
>  Nivel D       mensual    Nivel C   anual     Nivel B      +   Nivel A
>
> Es decir, el cálculo de la cuota anual se hace en el nivel B (y A), y el
> cálculo de la cuota mensual se hace, sabiendo la anual, en el nivel C.
>
> Problema: que dependiendo de cuál sea la clase del nivel D, tendré que
> escoger una u otra clase del nivel B.
>
> Presupuesto que he seguido para la implementación:
>
> - Que la implementación de un nivel más bajo no dependa de la
>  implementación de un nivel más alto.
> - Que las clases del nivel D y B tengan la misma API (ya que al fin y
>  al cabo, implementan hipotecas, excepto por el hecho de que las del
>  nivel D tienen dos parámetros más de inicialización.
>
> Y ya no sé explicarme mejor.
>
> Muchas gracias por tu tiempo.
>
> [1]http://sio2.free.fr/hipoteca.py
>
> --
> Hay dos sistemas de conseguir la felicidad: uno, hacerse
> el idiota; otro, serlo.
>                  --- Enrique Jardiel Poncela. --
>   Si     Dióxido de Silicio |        Debian GNU/Linux
>  /  \         (SiO2)        |    José Miguel Sánchez Alés
>  O    O   Mineral de Cuarzo  |  sio2sio2 en gmail.com | URL #257033
> _______________________________________________
> Lista de correo Python-es
> http://listas.aditel.org/listinfo/python-es
> FAQ: http://listas.aditel.org/faqpyes
>