Lo más difícil en Delphi
En un comentario en esta página, Dani Coll menciona un nuevo lenguaje de programación, dentro de la categoría "for kids". Y se me ocurre una pregunta:
- ¿Qué es lo más difícil de entender para alguien que comienza a programar en Delphi?
Yo sé positivamente qué es lo que más trabajo me cuesta explicar, pero me interesa escuchar comentarios...
Ian Marteens, 4:45 p. m.
7 Comments:
En mi opinión no hay nada intrínsecamente difícil o complicado de entender en Delphi.
Precisamente el hecho de ser heredero de un lenguaje paradigma de los lenguajes estructurados como el Pascal, "ocultar" elegantemente el uso de punteros, soportar herencia visual de formularios,... simplifica su aprendizaje.
Aunque sí es cierto que los conceptos de OOP siempre pueden resultar complejos para el que los ve por primera vez.
Por otra parte, conocer las diferentes clases, propiedades y mètodos de los componentes de la VCL lleva su tiempo.
Bueno, para no mantener el misterio demasiado tiempo:
1- Por experiencia enseñando: para que la gente pille la idea de los métodos de clase, es complicado. Conozco gente muy buena, que lleva mucho tiempo con Delphi, y sin embargo no lo tienen demasiado claro.
Con esto hay un problema interesante: una cosa es tener constructores virtuales (que C# no tiene y Delphi sí), y otra cosa son los métodos de clase virtuales. Conozco usos para los constructores virtuales (más allá de la VCL) y para los métodos de clase al estilo Delphi... pero no conozco aún un buen ejemplo de uso de métodos de clase y a la vez virtuales. Por eso he ido postergando la implementación de las metaclasses en Freya.
2- De todos modos, cuando estoy en un curso inicial "de verdad", el problema más frecuente que me encuentro es comprender el sistema de ventanas. Quiero decir: la gente no ve a la primera la diferencia entre la variable global que Delphi declara para el formulario y la clase asociada. Sí: es un concepto clásico de P.O.O, el trío "clase-referencia-instancia". Pero la dificultad va más allá: cuando empiezas a explicar el modelo MDI... o cuando montas una aplicación SDI con un sistema complejo de ventanas, la gente se pierde.
No digo que sea difícil "en sí". Lo que quiero decir es que las ventajas, cualesquiera que sean, de la técnica de diseño visual en formulario, se detuvieron en ese nivel: en el formulario. Hay unas técnicas de "cableado" visual dentro de los formularios, que sin embargo, no se pueden aplicar directamente al nivel inmediato superior. Esto lo discutía con Montxo Latasa hace un par de días: cuando abres un proyecto, da igual si con Delphi o Visual Studio, ves una simple lista de formularios, sin relación visible entre ellos.
Ian,
Estoy totalmente de acuerdo contigo (no siempre :-) ).
Cuando lanzaste la pregunta también pensé en los métodos de clase.
En cuanto a que la relación entre los formularios és poco clara, tienes más razón que un santo! Es un comentario que estoy harto de repetir cada día. En un IDE con un montón de cosas (todas útiles ?), creo que no era demasiado trabajo tener un experto o ventana con un diagrama en forma de árbol o grafo indicando las diferentes relaciones entre los formularios (puestos a pedir, incluso de diferentes proyectos). Cuando se tienen muchos proyectos con muchos formularios que se usan entre sí y se ha abusado (o no) de la herencia visual, es una trabajo tedioso saber quien usa a quien.
Sres. de Borland (GExperts estais ahí?), el TreeView está bién, pero que tal un ProjectFormsView ?
P.S: A lo mejor existe esta herramienta y yo la desconozco. Si és así, ilustradme.
Saludos.
(Perdón, pero no sé cómo se quotea, así que lo haré a mano)
[Ian]
> para que la gente pille la idea
> de los métodos de clase, es
> complicado
Chico, pues en clase no lo explicarás como en tu Cara Oculta (ese que me dedicaste en un SIMO hace años, ¿cuántas veces te han pedido que dediques un libro técnico? ;-) pues debo decir que lo entendí a la primera (y no me considero superdotado). Lo que sufrí (y mucho) fue pasar de una programación lineal a otra orientada a eventos. Con los objetos ya había cacharreado un poco con Clipper y sabía (vagamente) qué eran.
> la gente no ve a la primera la
> diferencia entre la variable
> global que Delphi declara para
> el formulario y la clase asociada
Touché. Me has pillado.
[Dani]
> que tal un ProjectFormsView ?
Existe algo para ver en forma de arbol la herencia visual de los formularios (lo siento, ahora no tengo Delphi delante y no sé cómo se llama la ventana) pues uso y abuso en mis proyectos de ella y recurdo que hasta que no la descubrí me volvía loco para saber de quién descendía quién. No sé si eso es lo que buscas...
Hay un explorador de clases, y puesto que los forms son clases, esto te servirá.
Puedes acceder desde el menú "View->Browser" o bien pulsando "SHIFT+CTRL+B".
Un saludo.
Ian tiene razon:
" la gente no ve a la primera la diferencia entre la variable global que Delphi declara para el formulario y la clase asociada". Además algunos pensamos que tener una variable global es horrible, además cuesta trabajo deshacerse de ella. Además los módulos de datos ligados en diseño (al quitar estas variables) parecen seguir compartiendose como si fueran globales. ¿Alguien me puede aclarar a que se puede deber este problema?
La clave está en que se mantiene una lista con todos los módulos. Cuando alguien hace referencia cruzada desde un formulario a un componente dentro de un módulo, lo que el DFM guarda es una cadena como 'DataModule1.ClientDataSet1'. De modo que lo primero que hace el cargador de formularios es buscar un módulo con ese nombre... en la lista de módulos ya creados. El que no haya una variable global no lo impide, porque no se usa esa variable global. Otro detalle: es posible también porque hay una propiedad Name en el módulo, donde se guarda también el nombre en tiempo de ejecución.
En .NET se pasa al otro extremo: no se manejan referencias a componentes en otros formularios, más o menos como ocurría en Delphi 1 (las referencias entre formularios aparecieron en Delphi 2). Para el que empieza, parece un paso hacia atrás, pero no lo es: se "desliga" o "desacopla" la relación entre formulario y módulo de datos. Además, ADO.NET es mucho más "desconectado" que DataSnap.
Publicar un comentario
<< Home