Hola:
Roman ecribió:
Cita:
|
Si vamos a utilizar estas propiedades protegidas (Row y Col) una sóla vez entonces lo más adecuado es el truco; pero si vamos a estar utilizándolas regularmente lo mejor es derivar la componente e instalarla.
|
Esto sí es llegar a un extremo. No pongo en duda la validez de tu truco, pero ¿qué ocurre si tenemos en un proyecto 20 forms con sus respectivos DBGrids, con todas sus propiedades Columns asignadas y deseamos acceder a su propiedad Col o Row? No creo que sea conveniente tener que colocar otro componente en la paleta sólo para cubrir esa necesidad, a parte del trabajo extra que supondría en este caso concreto volver a insertar los TUPDBGrid (por cierto no estaría mal que Delphi permitiera promover Controles a otros de su misma jerarquía, parecido a como hace MS Access para cambiar un control Edit a un Combo, copiando las propiedadees comunes).
El detalle en que quise incidir en mi mensaje anterior es en la particularidad de poder saltarnos a la torera la encapsulación para acceder a variables privadas cuando nos encontramos en la misma unit donde se declara la clase. Como dije, en un principio me sorprendió, incluso lo veía ilícito desde el punto de vista de la OOP, sigo creyendo que se salta las reglas, aunque luego he ido viendo sus ventajas. Me refiero a clases que no tienen un ancestro común (salvo TObject o TComponent claro está) y que sin embargo necesitan establecer una comunicación que sólo se les permite por el hecho de estar definidas en la misma unit. Quizás por ello haya units hinchaditas de tamaño, porque no hay forma de separar la implementación de ciertas clases.
Un saludo
02-06-2003
Modo Hilado