Presentacion (Era Definir Listas Globales)

[Andres Moya]

El mié, 10-03-2004 a las 14:33, Antonio Castro escribió:
> On Wed, 10 Mar 2004, Andres Moya wrote:

> > clases-función sólo es aconsejable en algunos casos particulares, pero
> 
> No estoy seguro. Este podría ser precisamente el caso.

Según la teoría que yo suelo aplicar, esos casos son cuando la función
es también un dato por si mismo, por ejemplo, cuando hay que pasarla
como parámetro a algún sitio.



> > en general contradice la teoría de orientación a objetos, que dice que
> > un objeto es un tipo abstracto de datos.
> 
> Eso lo puedo entender pero es que no se trataba de implementar un objeto
> sino una función. Aunque las cosas no son blancas o negras yo veo un
> objeto como algo que sirve para manejarlo y hacer cosas con él y
> una función como algo que básicamente hace algo bastante concreto.
> 
> Claro podemos crear y usar una función X() de la forma siguiente:
> 
> 		instanciaX=ClaseX()
> 		instanciaX.X()
> 		del instanciaX
> 
> Pero si solo interesa usarlo como X()  **podría**   ser una opción
> meter dentro de la función el objeto para uso interno nada más.


Lo del singleton te lo he dicho precisamente por eso. Si las variables y
las funciones son estáticas, te evitas tener que instanciar el objeto.
Lo que tienes es una función normal y corriente, con unas variables y
unas funciones auxiliares encapsuladas dentro de una clase. En el
ejemplo que te mandé, la llamada sería:

  MiClase.funcionPrincipal()


> > Este caso se puede solucionar de maneras mejores. Por ejemplo, usando un
> > estilo procedural típico, lo más fácil es pasar esas variables como
> > parámetro:
> >
> >   def funcionPrincipal(...):
> >     var1 = ...
> >     var2 = ...
> >     fun1(var1, var2)
> >
> >   def fun1(var1, var2):
> >     ... # Si la función modifica las variables, hay que devolverlas al
> >         # final con return (en python se pueden devolver varios valores)
> 
> Tuve problemas para usarlo así. No recuerdo exactamente el motivo pero
> era cosa de las librerías que uso. self.funcionX(algo) debe ser recibido
> como def funcionX(self, algo) y cuando la funcionX es tuya no hay
> problema en adaptarla,  pero cuando es la funcion de una librería
> que espera cierto número de argumentos, y  si ese algo que quieres pasar
> debe ser manejado en alguna otra función, es cuando se me crea el problema.


¿Y la tercera opción no te vale? Crear una clase que encapsule var1 y
var2, junto con posiblemente algún método de acceso, y luego pasarla
como parámetro desde la funcionPrincipal a las otras. De este modo las
funciones auxiliares pueden cambiar var1 y var2 libremente, porque están
dentro del objeto pasado.

La verdad, es difícil dar soluciones más afinadas sin conocer nada del
problema. Ya me ha entrado la curiosidad, ¿está visible tu código en
algún sitio?

(eso sí, no garantizo que tenga tiempo de mirarlo mucho)

-- 
Andres Moya <Andres.Moya en hispalinux.es>

Contra la guerra global permanente.
Foro Social Mundial - Otro mundo es posible.

------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es