Un problema de herencia múltiple.

[José Miguel Sánchez Alés]

(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