Derivacion condicional

lasizoillo lasizoillo en gmail.com
Vie Jul 13 11:21:36 CEST 2007


Asi explicado la cosa parece mas facil.

Premisas:
- C tiene que comportarse como A o como B dependiendo de algo (que mas
da que). Por ahora nos olvidamos cual es la forma de hacerlo.
- C, A y B comparten un interfaz comun.
- Nos interesa trabajar con objetos de tipo C por algun motivo, por lo
que descartamos el duck-typing.
- D, E, F, ... heredan de C.

Propuesta 1 que ya te han dado:
C es un interface de A y de B. A y B heredan de lo que tengan que
heredar y de C.
D, E, ... heredan tranquilamente de C, pero no sabemos como decirle
que implementar. No se me ocurre una forma elegante de decirles que
usen la implementacion de A o de B.

Propuesta 2, nos olvidamos de la herencia:
Definimos una clase C que no hereda de ninguna otra.
Esta clase C sabe ver ese algo de lo que depende para usar A o B. A y
B comoponen a C, C elige cual usar "decorando" a una de estas dos
clases.
D, E, .... heredan tranquilamente de C. No nos molestamos en decirle
si queremos que C se comporte como A o como B porque C es ya muy listo
y sabe hacer las cosas.

Creo que la segunda propuesta no es nada dificil de implementar. Seria algo asi:

class C:
  def __init__(self):
    #TODO: dispatching a mejorar
    if algo:
      self.__c_inst = A()
    else:
       self.__c_inst = B()
  #Ejemplo de una funcion que se ejecuta con la implementacion de A o
B dependiendo de algo
  def pinta(self, loquesea):
    log.info("Entro en pintar") #Puedo añadir "funcionalidad" en C
    self.__c_inst.pinta(loquesea)
    log.info("Salgo de pintar)

Espero que esto te sirva de ayuda



El 12/07/07, Oswaldo Hernández <listas en soft-com.es> escribió:
> Chema Cortes escribió:
> > El 12/07/07, Oswaldo Hernández <listas en soft-com.es> escribió:
> >> Chema Cortes escribió:
>
> > Supongo que lo debes tener claro; pero es dificil saber qué es lo que
> > buscas sin ver el grafo de herencias que tienes previsto. Por la
> > respuesta que has dado a Gerardo sospecho que las metaclases tampoco
> > te van a servir.
>
> El esquema de clases vendria a ser algo asi (debia de haber empezado por aqui :( )
>
> Clases A y B:  derivan de distintos objetos wx y establecen un interface comun para ellos.
>
> Clase C es la que, en funcion del entorno o de los parametros, decide si se ha de utilizar A o B,
> ademas de añadir algunos metodos.
>
> Clases D, E, ... derivan de C y son las que establecen las propiedades y metodos finales para la
> funcion a realizar. Estas clases finales no tienen que preocuparse sobre si se esta utilizando A o B.
>
> Algunos posibles usos:
>
> - Modificar todo el interface de una aplicacion cambiando simplemente el valor de una variable
> global. (esta es facil)
>
> - Decidir segun los datos a mostrar en un widget wx si se ha de utilizar un TreeCtrl, un ListBox, o
> un Choice.
>
> - Mostrar u ocultar cierta información en funcion del usuario que ha establecido la sesión, la ip
> del equipo, etc.
>
> El objetivo de todo esto es que los programadores que realiza las clases finales que derivan de C no
> tengan que preocuparse sobre muchas de las cuestiones de aspecto, privacidad, etc ..
>
>
> --
> *****************************************
> Oswaldo Hernández
> oswaldo (@) soft-com (.) es
> *****************************************
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es
>




Más información sobre la lista de distribución Python-es