 |
 |
|
|
Koan #3: Todos los animales son iguales, pero algunos son más iguales que otrosVaya título para un koan ... pero de algún modo contiene la respuesta. Intentaré explicarme, y esta vez recurriré a su imaginación gráfica para plantearle el aparente problema. ¿Se ha puesto a pensar alguna vez en la cantidad de componentes que publican propiedades de tipo TStrings? El cuadro de listas (TListBox) tiene Items, al igual que el TComboBox; el TMemo y el TRichEdit utilizan Lines... - ¡Ah! Este Ian va de listo - dice una voz crítica dentro de mi caja craneal - y quiere hacerse el iluminado contando la diferencia entre TStrings como clase abstracta, y TStringList como clase concreta, que implementa todos los métodos abstractos de TStrings. Pues no vamos por ahí: es posible que hablemos de clases abstractas y concretas, pero también de cosas más interesantes. El problema que he detectado en muchos programadores de Delphi, es que piensan en un TListBox (pongamos por caso) mediante una imagen similar a la siguiente:
Es decir: el TListBox es un objeto independiente, que tiene una propiedad Items de tipo TStrings. Como el tipo TStrings es una clase abstracta, "realmente" Delphi crea un TStringList y lo asocia a Items; a fin de cuentas, ¡esto es polimorfismo! Cuando uno inserta en el TStringList un nuevo elemento, de alguna forma el TListBox se entera y retoca el control de Windows asociado, para mostrar el nuevo elemento... Pudiera ser pero ... ¿no es ésta una implementación muy ineficiente? Pues el TListBox gestiona, como hemos dicho, un control nativo de Windows, y este control mantiene en memoria privada una lista de los elementos a mostrar. De ser cierto la explicación anterior, ¡estaríamos duplicando toda esta estructura interna dentro de Delphi (el supuesto TStringList sería una copia fiel del contenido del control)! Y Delphi tendría que encargarse de mantener sincronizadas ambas copias: cada operación en cada una de las estructuras debe repetirse en la otra. ¿Es realmente así? ¿Dónde nos hemos equivocado? |
