Hola amigos,

no consigo entender muy bien cómo se trabaja con clases que heredan de otras clases. Mi pregunta es de principiante, pero es que aún soy gamba pequeña. Sé que una clase hija puede heredar de otra clase padre, para lo cual tenemos que escribir al comienzo de la clase hija INHERITS Nombre_de_la_clase_padre. Y podemos de este modo recursivamente heredar una clase de otra hasta 16 niveles. Classe16 hereda de -> Clase15 hereda de -> Clase14... etc. Ahora bien, si en una de estas clases hemos definido una variable ¿Cómo nos referimos a ella en su clase hija, nieta, bisnieta...?

Un saludo y gracias

Hola y bienvenido

Si no me falla la memoria, había que usar la palabra clave "Super." para referirse a cualquier atributo de la clase padre. Pero de la clase inmediatamente ancestro, no a las "abuelas", "bisabuelas", etc

http://gambasdoc.org/help/lang/super?v3

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

jguardon escribió: [Ver mensaje]

Hola y bienvenido

Si no me falla la memoria, había que usar la palabra clave "Super." para referirse a cualquier atributo de la clase padre. Pero de la clase inmediatamente ancestro, no a las "abuelas", "bisabuelas", etc

http://gambasdoc.org/help/lang/super?v3

Saludos

En realidad, Super solo debe usarse si se esta reimplementando un método (definiendo uno con mismo nombre a un método en una clase padre), pero para ello se debe llamar a dicho método de la clase padre.

Lo que tu buscas es ME [0]. Aunque Super funcione, no es correcto ya que puede traer problemas.

http://gambasdoc.org/help/lang/me?v3

Saludos!

Hola y gracias a ambos por responder,

creo que lo he entendido . ME.VariableX nos permite acceder a la VariableX declarada en una clase antecesora [modificada, puede ser también, en una o varias clases antecesoras], independientemente del grado más o menos lejano de parentesco. ME vendría a significar algo así como "algún antepasado mío" sin importar cómo de lejano es ese "antepasado".

Saludos

sebikul escribió: [Ver mensaje]

En realidad, Super solo debe usarse si se esta reimplementando un método (definiendo uno con mismo nombre a un método en una clase padre), pero para ello se debe llamar a dicho método de la clase padre.

Cierto. Conviene refrescar conocimientos.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Alaplancha: con ese nick tendrías que invitarnos a comer unas gambas a la plancha

Si estás empezando con la programación orientada a objetos, deberías tener en cuenta que hay muchos autores que describen la POO de maneras incorrectas y que la implementación que hace cada lenguaje puede ser más o menos acertada.

Lo fundamental es que captes los conceptos esenciales, para lo que deberías preguntarte en 1er lugar ¿qué es la POO? ¿qué es un programa orientado a objetos?

La herencia no es una característica fundamental de la POO. Históricamente se ha usado en exceso y sus beneficios se han sobrevaluado, es decir, ¡¡se puede vivir sin la herencia!! y un programa no necesita usar herencia para ser orientado a objetos. Así que antes de considerar usar herencia tienes que considerar usar composición. Incluso podrías emular la herencia usando composición (aunque necesitarías usar algún mecanismo de instrospección y el código resultante no expresaría la verdadera relación conceptual entre las clases).

Tampoco se necesita la herencia para poder usar polimorfismo, excepto que uses un lenguaje de tipado estático que no posea mecanismos para emular un sistema de tipos dinámico.

gambas en esencia es de tipado dinámico, pero aparenta ser de tipado estático porque exige la declaración de los tipos de datos. Sin embargo, gambas provee dos tipos que permiten compatibilizar los tipos de datos: Variant y Object.

Esto permite emular en gambas lo que se denomina duck typing, que no es otra cosa que el reconocimiento del tipo de objeto por su comportamiento en lugar de hacerlo mediante la declaración explícita de un tipo de datos y su verificación estática (en tiempo de compilación). Generalmente los programadores Python lo explican así: Si se parece a un pato, nada como un pato, y hace cuac como un pato, entonces probablemente sea un pato.

En definitiva, lo que es esencial en la POO son los mensajes, es el hecho de que un programa orientado a objetos se compone de objetos que hablan entre sí (se envían mensajes) como medio para poder colaborar en la realización de diferentes tareas.

Esos objetos son pequeños, es decir que hacen una sola cosa y la hacen bien. Que hagan una sola cosa no signfica que ejecuten una única instrucción o algo así, significa que cumplen con una única responsabilidad perfectamente delimitada. Esa responsabilidad puede ser más abstracta o más concreta, al igual que la responsabilidad de un barrendero es muy concreta (barrer) y la de un presidente es muy abstracta --tanto que algunos a veces no hacen nada

Una responsabilidad más abstracta implica que el objeto no podrá cumplirla por sí sólo, sino que necesitará la colaboración de muchos otros objetos, al igual que un presidente necesita de una gran estructura burocrática que involucra a gran cantidad de instituciones y personas para poder dirigir un país.

Una responsabilidad más concreta implica que el objeto necesitará pocos colaboradores y en un caso extremo la responsabilidad podría ser tan simple y concreta que el objeto podría cumplirla completamente por sí mismo, sin ayuda de nadie

Esto en un lenguaje orientado a objetos puros se observa siempre cuando se mira el código de un programa al nivel de la implementación de los métodos, pero en un lenguaje orientado a objetos que no es puro (como gambas) es más difícil verlo, porque a ese nivel de detalle lo que se ve no son objetos, sino tipos de datos nativos relacionados mediante operadores.

Espero que te sirva. Cualquier duda, preguntas.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Hola Fabián,

muchas gracias por la respuesta. Lo de la invitación está hecho si algún día la corriente oceánica me lleva por esos mares de allá  

Es cierto que estoy empezando con la POO y que a veces los principiantes nos quedamos con lo más aparente y vistoso, sin preguntarnos en primer lugar cuál es la esencia que caracteriza a este modo de programación. Que gambas permita heredar (¡hasta 16 veces, qué bárbaro, qué borrachera de plancton!) no sirve de nada si uno no se pregunta la esencia de para qué es necesario heredar tantas veces y otras preguntas más filosóficas o esenciales que están a otro nivel más allá del ponerse enseguida a escribir código.

Por otro lado (¿me estoy yendo off topic?) tengo como la sensación extraña de que la POO te hace pensar cuando programas de un modo concreto (imaginemos que hay otros mundos posibles) para resolver el problema que tienes entre manos, y he leído que hay gente crítica con este modo, con las ventajas e inconvenientes que tiene, y las ventajas mal utilizadas debido a un mal aprendizaje desde el principio lo que hace no tener claros los conceptos básicos esenciales, que son los que tú apuntas Fabián.

Gracias de nuevo por la respuesta.

Un saludo

Citar:

 Que gambas permita heredar (¡hasta 16 veces, qué bárbaro, qué borrachera de plancton!) no sirve de nada si uno no se pregunta la esencia de para qué es necesario heredar tantas veces

Humor inteligente que no se ve muy a menudo, bienvenido sea.

Citar:

 y he leído que hay gente crítica con este modo, con las ventajas e inconvenientes que tiene

Las críticas más grandes y más infundadas que he escuchado alguna vez, provinieron del célebre Dijkstra:

“La programación orientada a objetos es una idea excepcionalmente mala que sólo podría haber sido originada en California.”

En clara alusión a que Smalltalk estaba siendo desarrollado en los laboratorios de Xerox en Palo Alto, California. Su objeción partía de su visión respecto de que la programación debía basarse estrictamente en métodos formales:

"Las técnicas requeridas para el razonamiento efectivo son bastante formales, pero mientras la programación sea hecha por personas que no las dominan, la crisis del software permanecerá entre nosotros y se considerará una enfermedad incurable. Y sabes lo que ellas hacen: son una invitación para curanderos y charlatanes, quienes en este caso toman la forma de gurus de la ingeniería del software."

También dijo esto:

"Es casi imposible enseñarles a programar correctamente a estudiantes que previamente estuvieron expuestos al BASIC: como potenciales programadores quedan mutilados mentalmente sin esperanza de recuperación."

Siempre fue muy provocativo en la forma de expresar sus ideas y en algunas de ellas parece que estaba equivocado.

El origen de su postura contraria a la POO era la forma en que propone razonar sobre los programas, él buscaba un método formal que permitiera razonar de un modo estrictamente matemático sobre los programas y que permitiera también demostrar su corrección (en realidad, se trataba de demostrar que el programa cumplía con los requisitos previamente planteados).

Para él, razonar un programa a partir de abstracciones de clasificación, generalización y composición en términos de objetos y sus clases ("es un", "es parte de", etc) y la visión de que la solución a un problema se plantee a partir de metáforas, era claramente un error gravísimo. Basta recordar que Dijkstra definió un método de verificación formal llamado "derivación de programas" que partía de la construcción previa de una especificación formal y proponía la aplicación sobre ella de un conjunto de reglas o primitivas que permitieran finalmente transformarlas en un programa ejecutable, de modo que el programa mismo fuera su demostración.

Dijkstra estaba muy centrado en una visión de la computación como "ciencias de la computación" él era un físico teórico que desarrolló varios algoritmos muy conocidos. Por el contrario Alan Kay tenía una visión muy diferente de la computación como una herramienta que debía permitir la expresión y el desarrollo creativo de la mente humana.

Más allá de todo esto, el principal problema de la programación orientada a objetos es que agrava un problema ya existente en la programación procedimental: lo que un programa realmente hace sólo se puede ver si es posible observar en tiempo de ejecución el código y las transformaciones que éste produce en los datos.

Sin embargo, el código mismo y cualquier tipo de diagrama, UML por ejemplo, son esencialmente vistas estáticas del programa, lo que conduce al programador a tener que imaginar y mantener en su mente una diversidad de situaciones posibles y combinaciones, algo muy similar a lo que sucede con un ajedrecista (y se sabe que los grandes maestros sólo pueden mantener una cantidad muy limitada de posibles combinaciones en su mente).

(Por eso para mí el diagrama más valioso de UML es el diagrama de secuencia, aunque su utilidad sigue siendo muy limitada)

En un programa procedimental, al menos el código nos muestra la sucesión de llamadas de una rutina a otra. En cambio, el código de un programa verdaderamente orientado a objetos, muestra mayormente clases (¡clases no objetos!) y los lugares en que esas clases se instancian pueden estar diseminadas a lo largo de todo el código fuente. Esto sumado a la naturaleza estrictamente colaborativa de los objetos, hace que la lectura del código para seguimiento de un caso obligue a atravesar gran cantidad de objetos y sus clases, lo cual (obviamente) es difícil y se hace tanto más difícil cuanto más extenso es el programa.

El código de instanciación y de invocación de métodos relativos a una tarea, si el programa está bien escrito, pertenece a objetos cuya responsabilidad es precisamente esa (objetos de reificación y objetos guión), pero encontrarlos en el código no es tarea sencilla y los IDE's no proveen ninguna facilidad para identificarlos fácilmente o automáticamente.

Esta es una de las razones por las que el desarrollo guiado por pruebas (TDD) es tan importante para la POO, porque le provee al programador la posibilidad de desarrollar paso a paso el programa a partir de pruebas unitarias, es decir, de ejemplos, de casos de uso, lo que constituye la visión dinámica del programa, aunque fragmentada. Por ello también son tan importantes las pruebas de integración, porque constituyen la visión dinámica del programa como un todo.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.