Articulo: Atributos de visibilidad en Delphi
 

Buenos días:
Les escribo con motivo de comentarles que he escrito un artículo en la Developer Network de Codegear y el mismo ha sido publicado.
Habla un poco sobre los atributos de visibilidad de clases, con algunas mejoras que se realizaron en las últimas versiones del Delphi (algo simple, pero para algunos puede ser interesante).

Los invito a que lo lean, y contribuyan con la calificación que crean adecuada

http://dn.codegear.com/article/37691

Saludos Amigos!

Hola,

Pues gracias por compartir el artículo con nosotros Marcelo. Sin embargo, uno no puede evitar ver las nuevas "cláusulas de visibilidad" como la solución a un problema, aunque tal vez sea sólo formal. En realidad, lo que uno espera del miembro privado de una clase es que este no sea accesible desde fuera de la propia clase, no también de la unidad donde se implementa la clase, cosa que es posible en Delphi, pero, no parece adecuado.

Quiero decir, ahora existe el "privado estricto", de manera que lo que se consigue es, precisamente, lo que se espera conseguir el "privado"... con lo que uno se pregunta varias cosas, desde su ignorancia. ¿Por qué motivo no se ha hecho "privado" al "privado", valga la redundancia, que ha tenido que venir un "privado estricto"? Con lo del miembro "protegido" estamos hablando de lo mismo. Y tan sólo se me ocurre una posible respuesta: porque se trata de proteger la compatibilidad "hacia atrás".

Pero, ojo a esto, porque, se está diciendo que los programadores de Delphi declaran los miembros de sus clases como "privados", cuando en realidad acceden a estos desde fuera de la clase en cuestión, aunque sea (ya sólo faltaría) desde la unidad donde se implementa la clase. Pero, en fin, creo que no hay para qué seguir, pues me parece que se comprende lo que quiero decir. Todavía estoy por pensar que hay algo por ahí escondido, y que, como suelo decir, se me escapa, porque, ¿puede ser tan simple esto?

Bueno. Ya voté al artículo Marcelo. Gracias otra vez. ;)

Porque afectarías muchísimo código ya hecho. Pero, además, cuando hay clases muy relacionadas, resulta muy engorroso que unas accedan a las otras a través únicamente de propiedades y métodos públicos. Toma en cuenta, por ejemplo, que cada acceso a una propiedad significa, la más de las veces, pasar por un método SetX que puede hacer varias cosas aparte de asignar un valor, y que no siempre son deseables en el uso "a bajo nivel", como lo es el acceso por clases relacionadas.

Otros lenguajes tienen otros mecanismos para el acceso a elementos privados de una clase. En C++ existe el concepto de clases 'amigas', por ejemplo. En delphi se hace la "amistad" al colocar las clases en una misma unidad.

Claro que se puede argumentar el por qué de esa necesidad, como en este texto que acabo de leer:

El texto proviene de un foro de PHP, lenguaje en donde muchos acostumbran poner una sola clase por archivo, pero el caso es que la VCL está plagada de clases "amigas".

Yo más bien me preguntaría ¿cuál es la necesidad de agregar un atributo más restrictivo? Pero mejor me voy a leer el artículo del compañero para enterarme.

Bye

Marcelo:

Quizá esté equivocado, pero me parece que hay una errata en tu artículo. En la descripción de strict protected, pones:

La parte señalada debiera decir Strict Protected, ¿no? Por lo demás, me gustó tu artículo, breve, pero muy ilustrativo para quienes se inician.

Bye

Hola, no puedo acceder al enlace. El navegador me informa de que el servidor tarda demasiado en responder ¿Tan congestinado está?:confused:

Bueno, a riesgo de meter leña al fuego, y desconociendo las nuevas posibilidade de las visibilidades en nuevas versiones (yo trabajo con D6) y viendo lo dicho por Dec, debo hacerles recordar que la existencia de la sección private, public, protected, published existen para ofrecer lo que se conoce como el patrón Variaciones Protegidas.

Por ejemplo, cuando uno ofrece una propiedad pública mediante los debidos métodos de lectura y escritura, ofrece un mecanismo de protección a los miembro privados, que es donde realmente descansa el estado y/o valores de los objetos.

Será responsabilidad de los métodos de acceso (SetPropiedad, GetPropiedad) garantizar la debida consistencia de información y estado del objeto. Ocultando los miembros nos evitamos posibles daños colaterales y dejamos a disposición de los clientes (quien usa la clase) lo adecuado para su uso.

Leyendo lo dicho por Dec, me pregunto ¿Qué utilidad tiene un privado dentro de un privado? ¿A eso te refieres?:confused:

Recordemos que la POO descansa en algo que muchas veces decimos y rogamos: ocultamiento de información. Y en ocasiones nos pasamos por alto lo que signifca esa "simple";) frase.

Lo que hace falta no es aprenderse y leerse mil articulos sobre la visibilidad, sino fomentar el uso del análisis y diseño de objetos. Al menos, asi lo creo yo.

Saludos,