jueves, marzo 02, 2006

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 positivamente qué es lo que más trabajo me cuesta explicar, pero me interesa escuchar comentarios...

9 Comments:

Blogger Daniel said...

Bueno, desde mi punto de vista, se podrian separar en varias partes: por ejemplo entender las herramientas que ofrece la IDE, por ejemplo.

Pero si nos centramos un poco mas en el lenguaje, lo que puede ser un poco complicado son el uso de propiedades y metodos, y la idea de que todo codigo util dentro de la aplicación debe ser activado por un evento.

Tal vez, en estos tiempos no es tan grande la curva de aprendizaje de un lenguaje a otro, pero cuando empece con Delphi, yo pase por los clasicos programas de C++, y una programacion lineal-secuencial, para luego entender la programación orientada a eventos.

jueves, marzo 02, 2006 7:52:00 p. m.  
Blogger Dani Coll said...

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.

jueves, marzo 02, 2006 9:12:00 p. m.  
Blogger Ian Marteens said...

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.

jueves, marzo 02, 2006 11:24:00 p. m.  
Blogger Dani Coll said...

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.

viernes, marzo 03, 2006 8:21:00 a. m.  
Anonymous Anónimo said...

(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...

viernes, marzo 03, 2006 10:17:00 a. m.  
Anonymous Anónimo said...

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.

viernes, marzo 03, 2006 10:44:00 a. m.  
Blogger yop said...

Hola

Sin lugar a dudas herencia y reutilizacion de código.

saludos

viernes, marzo 03, 2006 1:27:00 p. m.  
Anonymous Anónimo said...

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?

jueves, marzo 09, 2006 1:04:00 p. m.  
Blogger Ian Marteens said...

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.

lunes, marzo 13, 2006 9:05:00 p. m.  

Publicar un comentario

<< Home