Re: [Objectbase-devel] Voluntario: Codificación de funcionalidad de reflection

[Jorge C. <jor...@ya...>]

No me convence mucho la idea de permitir realizar
queries por atributos privados (o protected... lease
no públicos).

De hecho todo debería hacerse utilizando métodos y no
los atributos.

Violar la encapsulación para persistir el objeto es
algo que "no afecta" el modelo y en cierto sentido no
viola la encapsulación de una manera "visible" al
usuario. En cambio realizar un query
objeto.atributo_privado == dodo es claramente una
violacion de la encapsulación! y peor aún es realizada
por el usuario (el mismo dice eso).

Si existe el caso donde se quiera buscar por algo
privado es muy probable que ese algo no sea privado o
haya algún error en el modelo.

Jorge


--- Nicolas Passerini <npa...@cu...> wrote:
> En función de esto, yo decía que el lenguaje no
> necesitaría en principio diferenciar entre getters y
> 
> atributos, ejemplo: si yo pido documento.pais busca
> primero un getPais() y si no lo encuentra busca el 
> atributo pais.
> 
> El lenguaje se podría extender un poquito para
> bypasear ese comportamiento que sería el default,
> ahora no se 
> me ocurre nada mejor que agregarle un chirimbolo
> (algo como documento.#pais) que indicaría que aunque
> exista 
> getPais() yo quiero al atributo. No me preocupa
> demasiado que quede muy lindo porque sería algo muy
> raro de 
> usar. De hecho creo que habría que discutir si está
> bueno ponerle ese feature.
> 
> También podría haber opciones para pedir un método
> sí o sí, una simple es documento.getPais(). (No sé
> si me 
> gusta mucho). 
> 
> Otra que habría que pensar es si siempre se accede a
> los métodos/atributos aunque sean privados o en
> algún 
> caso me interesa asegurarme de que le estoy pegando
> a la parte pública del objeto (¿y protected?). Si es
> así 
> habría que pensar extensiones para eso.
> 
> Igual creo que lo importante es mantener la
> simplicidad del caso más común, que creo que es
> -pegarle a cualquier elemento sea público o privado.
> -buscar primero el método y si no está el atributo.
> Para ese caso usaría 'documento.pais', si los demás
> son un poco más complicados no me jodería.
> 
> -----Original Message-----
> From: Hernan Liendo <her...@de...>
> To: ObjectBase SF
> <obj...@li...>
> Date: Sat, 27 Dec 2003 23:05:56 -0300
> Subject: [Objectbase-devel] Voluntario: Codificación
> de funcionalidad de reflection
> 
> > 
> > Necesito que alguien evalue, diseñe y desarrolle
> un módulo que me
> > permita acceder a cierta propiedad de un objeto
> dentro de una jerarquia
> > de objetos sin que estos sean necesariamente
> beans.
> > 
> > Ejemplo:
> > 
> > tengo este dominio de objetos
> > 
> > Class: Cliente
> > +getDocumento:Document
> > +setDocument(Documento)
> > ...
> > 
> > Class: Documento
> > +getPais:Pais
> > +setPais(Pais)
> > ...
> > 
> > Class: Pais
> > +getNombre:String
> > +setNombre(String)
> > ...
> > 
> > Si yo tuviera una instancia de cliente y quisiera
> conocer el nombre del
> > pais al que corresponde su documento utilizando
> > common-beanutils yo podria tirar:
> > 
> > String _nombrePais =
> BeanUtils.getProperty("documento.pais.nombre",
> > _cliente);
> > 
> > Eso funciona perfecto si las clases son beans y es
> lo que estoy usando
> > con composite queries. 
> > Lo que se necesita que es esto funcione tambien en
> objetos no-beans. 
> > 
> > Deberiamos pensar en un lenguaje similar al
> "documento.pais.nombre" que
> > sea sencillo
> > de usar y que pueda expresar como llegar a una
> propiedad de un objeto
> > interno.
> > 
> > La propiedad puede ser un atributo o un metodo. 
> > 
> > Como regla general: todo lo que pueda inferir es
> mejor, si no se puede
> > inferir o toma un matiz "dificil de que
> > alguien entienda como funciona" mejor que no
> infiera. Por ejemplo, se
> > puede inferir si algo es metodo o atributo.
> > 
> > Creo que esto esta bueno para desarrollar entre
> una o dos personas. 
> > El mecanismo seria ir tirando las ideas ANTES de
> codificar.
> > 
> > SaludOBs
> > 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux
> Tutorials.
> Become an expert in LINUX or just sharpen your
> skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the
> bash shell to sys admin.
> Click now!
>
http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Objectbase-devel mailing list
> Obj...@li...
>
https://lists.sourceforge.net/lists/listinfo/objectbase-devel


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/