Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





C++ y POO

Iniciado por sukhur, 05 de Enero de 2007, 10:12:24 AM

« anterior - próximo »

Fran

Cita de: "shephiroth"
Cita de: "Vicente""- si tienes un panel con 2 botones y un listbox, y quieres acceder al elemento seleccionado del listbox, crees que funciona el iterar sobre todos los controles contenidos en el panel preguntando por su selecteditem? O que te tocará preguntar por su tipo para ver si es un listbox?"

Este ejemplo tal cual esta expuesto me parece mal planteado. Si tienes un panel con varios botones y un listbox y quieres acceder al listbox, pues accedes directamente. Si tienes todos los controles vectorizados segun la clase base CWnd seguro que tienes necesidades de cosas raras (o getType como quieras), pero creo q eso se debe mas a una mala planificacion de tu clase que a una obligacion heredada del uso de POO. Pero si sigues pensando lo mismo, ponme un caso real, que quedandonos en medias pintas es normal que no nos entendamos.

Cita de: "Diferencial"Fran como resolverias el problema que ha planteado Vicente. (Java) Por ejemplo yo tengo una lista y varios botones en mi interfaz. Cada uno tiene asignado su metodo addActionCommand() en la misma clase que implementa ActionListener. Dentro del metodo actionPerformed() como sabes tu que objeto ha provocado el evento??

Por cierto se parece bastante al problema que se planteo desde el principio donde se quiere meter todo dentro del mismo vector.
Por fin, un ejemplo claro. Me aventuro mucho pq en java por lo que leo cambian las cosas mucho respecto de c, pero intentaré.

Que diferentes botones creen un evento y recaiga sobre una funcion comun para ambos me parece una locura. Yo cuando hago formularios los botones solo comparten funcion si no se hace referenia ninguna al control que lanzo el evento. Pero aun asi, si por alguna razon lo necesitase, no se si en java existe pero en los winforms existe una propiedad (heredada de Control) llamada FOCO, el cual lo tiene (salvo que el programador lo cambie a mano) el control que lanza el evento.

Aunque como digo mas arriba, me parece una mala programacion el que diferentes controles tengan eventos que apunten a una funcion comun la cual necesita diferenciar que control lanzo el evento.

Es que si la pregunta es esa ( q es lo q me ha parecido entender) no ha lugar xq cada control tiene sus propios eventos (sus Listener). Luego no es necesario hacer nada de ese estilo. Y si lo haces, pues usa lo q queras, pero no se hace asi. Coincido contigo de q además es un chocho.

Jare

Preguntar si un determinado objeto es de una clase o no es un caso concreto de un problema más general: preguntar si un objeto tiene o no una propiedad o conjunto de propiedades. Estoy seguro de que todo el mundo ha hecho eso alguna vez. Basta de "chorradas" sobre si es "OOP" o no. :)

Lex


vincent

Lo que yo me pregunto es si a sukhur (quien hizo la pregunta inicial del post) le ha quedado algo claro de todo esto...
Desarrollo en .Net y metodologías http://devnettips.blogspot.com

Vicente

Cita de: "shephiroth"Este ejemplo tal cual esta expuesto me parece mal planteado. Si tienes un panel con varios botones y un listbox y quieres acceder al listbox, pues accedes directamente. Si tienes todos los controles vectorizados segun la clase base CWnd seguro que tienes necesidades de cosas raras (o getType como quieras), pero creo q eso se debe mas a una mala planificacion de tu clase que a una obligacion heredada del uso de POO. Pero si sigues pensando lo mismo, ponme un caso real, que quedandonos en medias pintas es normal que no nos entendamos.

Imaginate que tienes una función que se llama "PonerEnModoLectura" que recibe un panel y recorre su colección de controles y si son TextBox los pone en ReadOnly = true (una propiedad que por ejemplo no tiene un Button). Para hacer eso necesito saber si un control es de verdad un TextBox, y como esa función vale para cualquier panel no puedo acceder directamente a variables declaradas por ahí.

Lo que le pasa en el problema que planteaba sukhur es lo mismo que se ha dicho con el ejemplo de la ventana: estaba metiendo varias cosas diferentes (Camiones y Motos) en un contenedor que tenia cosas de la clase base (Vehiculos). La ventana es igual porque tiene un contendor de controles pero en realidad dentro hay muchas cosas diferentes.

Pues en ese caso te toca castear. En el ejemplo de los Camiones y las Motos, si puedes modificar el código, pues podrías tomar como solución lo de la función virtual vacia (que a mi me sigue sin gustar), pero si no puedes el casteo no te lo quita nadie...

Un saludo!

Vicente

Edit: respecto a lo de Java, el caso que comentá Diferencial no es tan raro porque en Java para declarar un manejador de eventos te toca declarar una clase entera (no como en .NET), con lo cual no es raro declarar una clase con el actionListener y hacer un switch muy grande por el tipo, nombre o lo que sea del control para diferenciarlo. Porque si no si tienes 10 botones te tocaría declarar 10 clases (sin meternos en que podrías usar clases anónimas para implementar el listener).

Fran

Cita de: "Vicente"
Cita de: "shephiroth"Este ejemplo tal cual esta expuesto me parece mal planteado. Si tienes un panel con varios botones y un listbox y quieres acceder al listbox, pues accedes directamente. Si tienes todos los controles vectorizados segun la clase base CWnd seguro que tienes necesidades de cosas raras (o getType como quieras), pero creo q eso se debe mas a una mala planificacion de tu clase que a una obligacion heredada del uso de POO. Pero si sigues pensando lo mismo, ponme un caso real, que quedandonos en medias pintas es normal que no nos entendamos.

Imaginate que tienes una función que se llama "PonerEnModoLectura" que recibe un panel y recorre su colección de controles y si son TextBox los pone en ReadOnly = true (una propiedad que por ejemplo no tiene un Button). Para hacer eso necesito saber si un control es de verdad un TextBox, y como esa función vale para cualquier panel no puedo acceder directamente a variables declaradas por ahí.

Lo que le pasa en el problema que planteaba sukhur es lo mismo que se ha dicho con el ejemplo de la ventana: estaba metiendo varias cosas diferentes (Camiones y Motos) en un contenedor que tenia cosas de la clase base (Vehiculos). La ventana es igual porque tiene un contendor de controles pero en realidad dentro hay muchas cosas diferentes.

Pues en ese caso te toca castear. En el ejemplo de los Camiones y las Motos, si puedes modificar el código, pues podrías tomar como solución lo de la función virtual vacia (que a mi me sigue sin gustar), pero si no puedes el casteo no te lo quita nadie...

Un saludo!

Vicente

Edit: respecto a lo de Java, el caso que comentá Diferencial no es tan raro porque en Java para declarar un manejador de eventos te toca declarar una clase entera (no como en .NET), con lo cual no es raro declarar una clase con el actionListener y hacer un switch muy grande por el tipo, nombre o lo que sea del control para diferenciarlo. Porque si no si tienes 10 botones te tocaría declarar 10 clases (sin meternos en que podrías usar clases anónimas para implementar el listener).

Para hacer lo de los botones según el lenguaje hay mecanismos mas simples y mas rapidos. Por ejemplo en Delphi está el tag. Eso mismo puedes implementarlo en todos los demás. O las listas de comportamiento (q normalmente es lo q mucha gente hace para no tener q estar metiendo bucles en todos sitios para recorrer los controles de la pantalla y tenerlo todo centralizado).

En cuanto a lo de Java .... pues a mi no me ha hecho falta nunca un getType para implementar lo q dices. Xq cuando hay pocos contrales le pones a cada uno su EventListener q como bien sabrás es q en algunos casos como por ejemplo una barra de desplazamiento o un deslizador no te qda otra (xq además clarifica mucho más el código) pero es q en el caso de q quieras reducir el número lo q he visto muchas veces hecho (aunq yo no lo hago xq EN MI OPINIÓN enchocha mucho el código y lo q es peor no te deja reutilizarlo), pero repito lo q normalmente he visto hecho es crear un eventlistener del tipo q te haga falta para botones y luego solo tienes q identificar cual es y asi para cada tipo de control. Aunq para mi eso vale si solo tienes una pantallita (una aplicaciíon de una pantallita). Si tienes bastantes yo los hago uno a uno xq normalmente siempre una cosa te vale para otra y he podido siempre reusar mucho código definiendo un eventlistener propio para un tipo de control y o biuen creándome el control con ese eventlistener ya implementado como una clase nueva o bien creando el comportamiento si lo quiero implmentar en mas de un sitio xq es raro q no se repitan entradas de datos, etc en una aplicación y como tú dices habrái q copiar y pegar o reescribir continuamente el código amén de lo de RTTI (q es casi lo de menos)). Ejemplo a esto : una entrada en un text_box de un tipo de dato característico para validarlo y demás (una clave, una fecha (para controlar q se te mete con una máscara) etc...) ... Y asi todo. No hace falta para nada en ese caso. De hecho PARA MI lo único q hace es liar el tema programar asi.

Vicente

Lo de los botones supongo que te refieres a los TextBox del ReadOnly, y es solo un ejemplo, ejeeeemplo. Seguramente Jare con lo del "saber si un objeto tiene una propiedad" lo ha explicado mejor que yo.

[OT]
Respecto a lo de Java: reconozco que no recuerdo mucho Java porque hace años que no lo toco. Pero, si tienes 10 botones tus alternativas son (quitando las clases internas):

A) hacer 10 actionsListeners para ellos (usease declararte 10 clases, instanciar y levantar 10 clases en memoria, tener 10 ficheros de java más por ahí danzando, etc etc etc).
B) hacer 1 actionListener y dentro de ese actionListener tener un switch que diferencia entre los 10 botones (por nombre o como sea).
C) algo entre medias.

Lo de que el caso B solo vale para aplicaciones de una pantallita pues ni idea, porque nunca he hecho nada especialmente grande en Java. Pero vamos, el caso A no es precisamente barato...
[/OT]

Un saludo!

Vicente

Diferencial

Vicente mejor explicado imposible
PARA TENER COSAS QUE NUNCA HAS TENIDO, TENDRÁS QUE HACER COSAS QUE NUNCA HAS HECHO.

Fran

Cita de: "Vicente"Lo de los botones supongo que te refieres a los TextBox del ReadOnly, y es solo un ejemplo, ejeeeemplo. Seguramente Jare con lo del "saber si un objeto tiene una propiedad" lo ha explicado mejor que yo.

[OT]
Respecto a lo de Java: reconozco que no recuerdo mucho Java porque hace años que no lo toco. Pero, si tienes 10 botones tus alternativas son (quitando las clases internas):

A) hacer 10 actionsListeners para ellos (usease declararte 10 clases, instanciar y levantar 10 clases en memoria, tener 10 ficheros de java más por ahí danzando, etc etc etc).
B) hacer 1 actionListener y dentro de ese actionListener tener un switch que diferencia entre los 10 botones (por nombre o como sea).
C) algo entre medias.

Lo de que el caso B solo vale para aplicaciones de una pantallita pues ni idea, porque nunca he hecho nada especialmente grande en Java. Pero vamos, el caso A no es precisamente barato...
[/OT]

Un saludo!

Vicente

Posyasta. Sigo sin tener razones objetivas para convencerme (y si he puesto bibliografia de prestigio q lo contraria) pero esto ha degenerado a una conversación de besugos (en los q me incluyo) en los q se ponen ejemplos de Java y no te acuerdas como funciona q no tiene nada q ver con lo primario. Los q querais usar RTTi hacedlo y ya está. A mi no me gusta y punto. Creo q hay modos menos costosos y más flexibles de hacerlo . Y aun asi si alguna vez tengo q hacerlo no tengo ningun problema en usarlo sin decir q es una patata.

Bye

chan

Creo que en general os estáis ofuscando un poco casi todos, es decir, yo creo que no existe una fórmula mágica que funcione perfectamente para todos los casos, por lo que en algunos será necesario utilizar RTTi y en otros será más aconsejable utilizar métodos virtuales.

Yo, viendo el problema y algunas respuestas que se han dado, tengo una duda:

1. Tenemos una clase base vehiculo.
2. Tenemos clases heredadas como moto, que implementan propiedades y funcionalidades que no existen en vehiculo.

,bien, si declaramos una variable de tipo vehiculo e intentamos agregarle los valores de moto (haciendo el casting correspondiente), ¿como%&%$ vamos a conservar los valores de la clase ampliada, si simplemente no existen en la clase padre a la que la estamos asignando?, es decir, de que sirve hacer ésto:

vehiculo v[0]= new moto('SE-3212-RR',105, 'Manillar aluminio',......);

, si dentro de vehiculo no vamos a poder contener algunas de las propiedades de moto, como por ejemplo el tipo de manillar='Manillar aluminio'.

Para lo único que veo útil en éste caso usar RTTi, es para hacer alguna operación básica común a todos los elementos que implementen a vehiculo, y creo que eso no es lo que se proponía en el problema; simplemente éste hombre tendrá que declararse tantos tipos como distintos objetos quiera instanciar: Moto miMoto; coche miCoche; ....

fiero

Hola chan,
El vector v es de punteros, no de clases.

saludos
www.videopanoramas.com Videopanoramas 3D player

chan

Citar
El vector v es de punteros, no de clases.

... por lo que al hacer la asignación realmente estamos guardando la dirección de memoria que hace referencia al objeto moto, y para poder usar sus métodos se le hace el casting:

(moto)v[0]->getTipoManillar();  

es eso, no?

fiero

Cita de: "chan"... por lo que al hacer la asignación realmente estamos guardando la dirección de memoria que hace referencia al objeto moto, y para poder usar sus métodos se le hace el casting:

(moto)v[0]->getTipoManillar();  

es eso, no?



((moto*)v[0])->getTipoManillar();
www.videopanoramas.com Videopanoramas 3D player

Pogacha

La POO se basa en llevar el problema a los dominios de la mente y no a los dominios de la codificación.
Un mensaje el cual debe ser referido a un tipo especifico hecho a un tipo generico es romper con la POO.
Preguntar que cilindrada tiene un vehiculo es romper con la POO.
Saludos

chan

ok, gracias por la aclaración fiero






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.