digresiones (era: Python vs Java C C++)

[Hernan Foffani]

Chema Cortes escribio:
> Hernan Foffani escribió:
>
>> mis preguntas eran algo retoricas.  no me refería tanto
>> al problema técnico en sí (que ya es bastante complejo) si no mas
>> bien al hecho de mantener toda la aplicación en un estado estable.
>>
>> por ej, puede darse el caso que la nueva clase C cambie un
>> determinado atributo "coleccion" de list a dict. todas las
>> instancias de C deberían recrear el atributo "coleccion" como dict
>> con el contenido de las list anteriores.
>> o si la nueva clase Cuenta cambia el atributo "titular" de la
>> clase Persona a la clase Cliente, todas las instancias de Persona
>> que sean atributos de instancias de la clase Cuenta deben
>> cambiar de clase a Cliente aún cuando tanto Cliente como Persona
>> no se hayan modificado per se.
>
> Me parece que no tienes enfocado correctamente el problema. Los
> atributos son referencias, sin importar el tipo de dato. Me da igual
> que titular sea una instancia de Cliente ó una instancia de Persona,
> puesto que ambas clases coinciden en estructura:

¡Pero por supuesto que los atributos son referencias!
¿Por qué presupones que ambas clases (Cliente y Persona)
coincidirían en su estructura? ¿Que sentido que el progrmador
pase a utilizar una clase en vez de otra en el atributo
titular de la clase Cuenta en ese caso?
Si solo cambia la implementación de algun metodo no voy a
renombrar la clase por eso. (aun en este ultimo caso habría
problemas)

Es razonable suponer que si el atributo titular de Cuenta
cambia de Cliente a Persona o viceversa es porque en el resto
de la aplicacion se harán invocaciones a metodos o atributos
diferentes.

> ....
>    def SetTitular(self,titular):
>      self.titular=titular
>    def GetNombre(self):
>      return self.titular.nombre

GetNombre estaria implementada en ambas clases. ese no es
el problema al que me refiero. (e incluso ahi...)

el problema surge si a partir de la actualizacion necesito
GetNumCliente (está en Cliente pero no en Persona). Entonces,
 - o cambio de clase a todas las instancias que son atributos
 de Cuenta.
 - o uso try/except por NameError antes de acceder a
 GetNumCliente en TODA la aplicacion.
 - o cualquier otra tecnica parecida a esta ultima.
 ¿y que se supone que haría la aplicacion si no encuentra
 el metodo?

Algun tiempo despues de la actualización de Cuenta, si se
crearon nuevas instancias de esa clase, habrá algunas instancias
(las viejas) que tendran como atributo titular objetos Persona
y otras (las nuevas) atributo titular objetos Cliente.
Listados, estadisticas, o lo que sea, que barra esas instancias
darían inconsistencias (imaginemos un listado mal formateado.)
¡El error no se podría reproducir!
Reinicias el servidor y ¡ala! todo funciona (ahora todos
los atributo titular son instancias de Cliente.)

> Incluso daría igual el cambiar una lista por un diccionario:
>
>    def __init__(self,coleccion):
>      self.coleccion=coleccion
>    def get(self,id_):
>      return self.coleccion[id_]

pero el que usa el get debe saber que hay instancias a las
que debe pasar un entero (las viejas, las que son listas)
y otras (las nuevas, dict) a las que debe pasar un string
o lo que el programador haya decidido usar como indice.

No me parece razonable escribir codigo de mas que nunca
se ejecutará luego del primer reinicio del sistema.

> Si está bien diseñado, bastaría con una actualización de los
> atributos.

repito, mis objeciones no son sobre la programación en python.
no creo que la forma de resolver el problema de las
actualizaciones de versiones en caliente sea cambiando
la clase de instancias en ejecucion.

> Más problemáticos son los cambios en las reglas de
> negocio. Aún así se puede minimizar los problemas si se emplea un
> buen diseño multicapa ("multi-tier"), de modo que los cambios en las
> reglas de negocio no influyan tanto en el resto de la aplicación.

Esto ya es otra cosa.