C++ y POO

[Pogacha]

En realidad no me molesta que la gente piense diferente (siempre te parecera tener los pelos del chancho en la mano antes de decir que son blancos), si y mucho cuando se pierde el respeto en una conversación.

Saludos

[Vicente]

A ver, yo estoy también de acuerdo con tamat y cia que su solución es la correcta (frente a la de Fran y shephiroth). No podéis poneros a aplicar las reglas de la POO a un problema que está claramente mal planteado (meter un montón de cosas diferentes en un contenedor y querer acceder a sus especificaciones en vez de a la de la clase común).

Imaginaos que sois desarrolladores y vais a usar una u otra solución:

- usais la de tamat y cia: ningún problema, os va a ir perfecto y seguramente el getType ese ni lo uséis porque no intentaréis hacer cosas que están mal pensadas.

- usais la de Fran y cia: vais a ver clases (como moto y camion) que tienen un montón de métodos QUE NO HACEN NADA. Y no vais a pensar: ostias que cracks, seguro que querían meter motos y camiones en un contenedor de vehiculos y poder acceder a sus funcionalidades y por eso tenemos un montón de métodos que casi al azar, hacen cosas o no hacen cosas. Lo que vais a pensar es que vaya chapuza de libreria, donde hay clases que tienen varios métodos declarados que no hacen nada de nada.

O vamos, así pensaría yo si viera eso... Un saludo!

Vicente

[shephiroth]

ZAELSIUS: Respecto a la programacion de scripts, ya se que hay problemas para los q son "necesarios" ciertas practicas. Pero como me parece que deje claro esos problemas se dan por practicas mas avanzadas que una simple POO. Para una POO basica NO SE NECESITA un getType. Aun asi, en tu ejemplo, utilizar metodos virtuales puede parecer engorroso si cada clase hija tiene metodos totalmente diferente. Pero esq en ese caso la base madre existe solo para poder vectorizar de mala manera, no por ventaja de POO.

Sobre gestion de errores, si nosotros somos los programadores finales esta claro que sabemos de que va el tema. Sino, que de errores bien gordos y buena documentacion. Asi el programador que los use fijo que no puede dejarse cosas en el aire. Sobre errores silenciosos, me parecen lo peor del mundo, luego que se reinicia windows sin venir a cuento...

ZUPERVACA: Yo no digo que lo de getType no sirva nunca, lo que me parece es matar moscas a cañonazos. Desde luego para un enunciado (aunque mal planteado) de POO basica me parece una burrada usar getType...

POGACHA: Te he de dar la razon, ahora que me releo el post la manera en que lo escrebi no es la adecuada. Pido perdon a todo el mundo  :oops:

VICENTE: En lo unico que estoy deacuerdo contigo es que el uso del getType depende de la situacion y que el ejemplo que se expuso esta mal planteado. Pero para un ejemplo basico de POO el getType es demasiado lioso. Esta claro que si lo pones no te va a dar ningun problema, pero como dice mi profesor de universidad "hay que evitar usar codigo muerto", es decir, codigo que no se va a usar. El getType hay que ponerlo cuando se necesita, no por costumbre.

SALUDOS ^^

[zupervaca]

pero como dice mi profesor de universidad "hay que evitar usar codigo muerto", es decir, codigo que no se va a usar. El getType hay que ponerlo cuando se necesita, no por costumbre.

Pues sin querer ofender, pero no se decirlo de mejor manera... tu porofesor no sabe de lo que habla, ya que si la funcion getType existe, pero no se usa, esta funcion no existira en el ejecutable final, mientras mas funcionalidad mejor y si no se usa no pasa nada, esta es una de las mejores cosas que tienen los compiladores de c/c++.

[shephiroth]

Me estas diciendo que los compiladores de c solo compilan lo que utilizas en vez de todo el codigo?? Bueno saberlo :)

P.D: Actualmente no estdio c en la uni, sino component pascal y java.

[Fran]

No me voy a leer el hilo xq me parece darle la vuelta a lo mismo. Solo digo que si te hace falta getType o RTTi a menudo,en mi opinion es q no has pensado bien tu jerarquia de clases . Para mi son algo CASI como el goto (no tan feo). Algo q a veces hace falta, pero en lo q no puedes basar una programación

[Fran]

A ver, yo estoy también de acuerdo con tamat y cia que su solución es la correcta (frente a la de Fran y shephiroth). No podéis poneros a aplicar las reglas de la POO a un problema que está claramente mal planteado (meter un montón de cosas diferentes en un contenedor y querer acceder a sus especificaciones en vez de a la de la clase común).

Imaginaos que sois desarrolladores y vais a usar una u otra solución:

- usais la de tamat y cia: ningún problema, os va a ir perfecto y seguramente el getType ese ni lo uséis porque no intentaréis hacer cosas que están mal pensadas.

- usais la de Fran y cia: vais a ver clases (como moto y camion) que tienen un montón de métodos QUE NO HACEN NADA. Y no vais a pensar: ostias que cracks, seguro que querían meter motos y camiones en un contenedor de vehiculos y poder acceder a sus funcionalidades y por eso tenemos un montón de métodos que casi al azar, hacen cosas o no hacen cosas. Lo que vais a pensar es que vaya chapuza de libreria, donde hay clases que tienen varios métodos declarados que no hacen nada de nada.

O vamos, así pensaría yo si viera eso... Un saludo!


Vicente

Yo sin embargo si veo muchas llamadas a RTTI o getType pienso: joder xq quieres casar lavadoras con capsulas espaciales???. En cualquier caso
te recomendaria que te vieras por ejemplo unos cuantos interfaces java. De ellos hay en ocasiones en los que solo usas 4 o 5 metodos. El resto es codigo muerto que como tu  dices (para mi no es asi) no vale para nada. Para mi vale para dar flexibilidad ante requerimientos no predefinidos. O te vieras el codigo de la VCL de Delphi a ver cuantas llamdas a RTTI ves (alguna pero pocas, casi ninguna).

[zupervaca]

Me estas diciendo que los compiladores de c solo compilan lo que utilizas en vez de todo el codigo?? Bueno saberlo :)

P.D: Actualmente no estdio c en la uni, sino component pascal y java.

Es lo que hacen y yo lo uso para optimizar muchas cosas, sobre todo las funciones virtuales, por ejemplo, tienes una clase base abstracta y dos derivadas que son para renderizar en ogl y d3d, si compilas las dos en el ejecutable las funciones virtuales seguiran siendolo teniendo que resolverse las llamadas a ellas en tiempo de ejecucion, ahora si compilas solo la del ogl o d3d el compilador resolvera en tiempo de compilacion las funciones virtuales con la consiguiente ganancia de velocidad.

Efectivamente en java no existe esta ventaja :( , no obstante tienes algunos ofuscadores que eliminan el codigo que no va a ser usado ahorrando espacio en el jar final :D, aunque no se exactamente si la eliminacion es por funciones y clases o solo por clases.

[shephiroth]

Los interfaces de java son otra cosa, con lo de codigo muerto (si lo decias por mi) me referia a crear funciones miembro que no se van a llamar nunca. Lo de dar flexibilidad.....es cierto que puedes dar cierta flexibilidad creando metodos alternativos.....pero una cosa es dar flexibilidad y otra cosa es trabajar de 2 maneras diferentes. Cuando creas una clase tienes q tener claro como trabajar con ella. Una vez tienes claro como trabajar, internamente haz toda la flexibilidad que quieras, pero publicamente la forma de trabajar tiene q ser una y solo una. Sino puedes estar creando una ambigüedad y dar muchos quebraderos de cabeza el pogramador que utilice tu clase.

SALUDOS ^^

Respecto a java, hemos empezado desde cero, y hasta el segun cuatrimestre no empezaremos con POO, asi que es un tema que no conozco, pero gracias por lo q dices ^^

[swapd0]

Un ejemplo, yo tengo hecho un ensamblador de risc y cisc (los dos juntos), las instrucciones las meto en un contenedor, y despues para buscar dependencias en los registros (solo en codigo risc), tenia que usar RTTI. No me gustaba como estaba echo, pero por lo menos me servia para comprobar si funcionaba bien  el optimizador de codigo.

Para solucionar esto, cree 2 clases, una para codigo cisc y otra para risc:

Código [Seleccionar] Expand


class CodeChunk
{
...
   virtual void FindDependecies() { ; }
};

class CiscCodeChunk : public CodeChunk
{
...
};

class RiscCodeChunk : public CodeChunk
{
...
   virtual void FindDependecies() { // codigo para buscar dependencias }
};


El codigo cisc va a CiscCodeChunk y el risc a RiscCodeChunk. Ahora no uso RTTI, no me gusta que FindDependecies() este vacio, pero me gusta mas que usar RTTI, que queda muy feo en el codigo.

[Vicente]

Yo sin embargo si veo muchas llamadas a RTTI o getType pienso: joder xq quieres casar lavadoras con capsulas espaciales???.

Claro, ese es el problema del ejemplo, casar cosas diferentes en la misma colección... Lo de implementar solo "trozos" de interfaces, podrá estar en la jdk (también he visto cosas similares danzando por el framework de .NET), pero eso no lo hace la solución buena. Es simplemente porque no te queda más remedio (ya que ese método si no se implementa es porque no tiene sentido, y no lo va a tener en la vida). De todas formas, MS por ejemplo recomienda encarecidamente no usar las interfaces para definir funcionalidad común ;) (usar clases abstractas mejor)

Un saludo!

Vicente

[fiero]

Hombre... lo de casar lavadoras con capsulas espaciales no es tan raro. Yo por ejemplo uso en mi programa una lista de objetos que pueden ser cosas muy diferentes, otra cosa es como te lo montes.
Por ejemplo, en un cuadro de dialogo de Windows, el diálogo mantiene una lista de todos los elementos dentro del diálogo, ya sean iconos, combos, botones, etc. Un icono tiene poco que ver con un combobox, y sin embargo los dos derivan de la clase común "ventana" (CWnd si se usa MFC, o identificadores HWND si se usa el API de Windows). Al preguntar al diálogo por cada elemento que contiene te devuelve punteros CWnd, y es el programador el que tiene que hacer un cast de ese puntero para usarlo como combobox o como icono.

En fin, que estas cosas no son tan extrañas como pueda parecer.

un saludo

[shephiroth]

Iconos, botones, combobox y todos los controles de un formulario no derivan de Window, derivan de Control. Es una clase especial creada para unificar todo lo que contiene un formulario, para unificar todo lo que se dibuja encima  de un formulario.

Un ejemplo claro de esto lo tendrías en el objeto Form.Controls. En el MFC todos los controles que creas son añadidos a esta coleccion, y se utiliza tanto para dibujar como a la hora de finalizar el formulario.

[Vicente]

Ya, pero no por ser todos controles la clase Control define todos los métodos que cualquier posible control pueda necesitar. Control simplemente define la mínima funcionalidad común, y si quieres un control específico necesitas algo como el getType ese.

Un saludo!

Vicente

[Fran]

8) Vamos a ver. No tengo a mi disposición (me la cargué hace ya años y he estado buscando pero no la encuentro) una jerarquia de clases que en su momento (año 92) me hice en C++ para hacer un GUI (con ventanas, botones, menus, combos... y todo eso) para MSDOS. No usé para nada GetType ni RTTI xq no estaban soportadas y además no me hacia falta. Pero es que a quien quiera convencerse y dado que no es lo q digamos unos u otros xq entiendo que lo q yo diga os tiene q ser tan indiferente como al resto lo vuestro,y dado que x lo q leo para muchos aqui una jerarquia de clases para un GUI es algo en lo que se debería usar profusamente el tema, os recomiendo leais una gran obra (de alguien q a día de hoy tiene en su haber dos grandes productos : Anders Helsberg  (Delphi y C# (es el arquitecto jefe)): la VCL de Delphi. Cuando encontreis en algo q no sea la conexion con activex un getType me lo decís. Yo os puedo decir donde se usan metodos virtuales vacios. Y hay unos cuantos en las clases base. Evidentemente para mi ese es un criterio. Fijarse en un grande. Y no en lo q diga alguien q usar RTTI es ortodoxo con la OOP y usar métodos virtuales y después redifinirlos no