FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
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!
__________________
Saludos. Marcelo D. Alegre |
#2
|
||||
|
||||
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. |
#3
|
|||
|
|||
Cita:
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: Cita:
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 |
#4
|
|||
|
|||
Marcelo:
Quizá esté equivocado, pero me parece que hay una errata en tu artículo. En la descripción de strict protected, pones: Cita:
Bye |
#5
|
||||
|
||||
Hola, no puedo acceder al enlace. El navegador me informa de que el servidor tarda demasiado en responder ¿Tan congestinado está?
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? 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, |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Visibilidad de un objeto instanciado en Form1 desde otra unit | lujansantos | OOP | 2 | 18-07-2007 16:33:13 |
Atributos css | Io | HTML, Javascript y otros | 3 | 13-02-2007 18:14:35 |
atributos | diniremix | API de Windows | 4 | 21-05-2006 01:48:26 |
Articulo -> Ventas - Borrar Articulo | hmoner | Conexión con bases de datos | 7 | 14-10-2005 18:24:54 |
Atributos RichEdit | jefamo | Varios | 2 | 08-07-2003 14:38:58 |
|