C++ y POO

[marcode]

Código [Seleccionar] Expand


Vehiculo{
.....
virtual getPlazoRevision(){result=4}
boolean getMeTocaLaRevision (dtFecha del tipo DateTime)
.....
}


Estas añadiendo esto para un problema puntual, pero ¿si te surjen mil problemas vas a añadir mil funciones virtuales?

En cuanto a las partículas, no todas tienen masa o carga, si tengo 5 protones y 1000 electrones no quiero calcular su atracción cero haciendo 1005*1005 operaciones, sólo quiero calcular la de los 5 protones.

De todos modos es mi opinión personal de cómo me parece mejor usar la POO en C++ (será porque vengo del C).

[Fran]

Código [Seleccionar] Expand


Vehiculo{
.....
virtual getPlazoRevision(){result=4}
boolean getMeTocaLaRevision (dtFecha del tipo DateTime)
.....
}


Estas añadiendo esto para un problema puntual, pero ¿si te surjen mil problemas vas a añadir mil funciones virtuales?

Claro. Mil o 500 o 1500. Las q hagan falta.Todavia no conozco el programa que resuelva mil problemas sin programarlo.

En cuanto a las partículas, no todas tienen masa o carga, si tengo 5 protones y 1000 electrones no quiero calcular su atracción cero haciendo 1005*1005 operaciones, sólo quiero calcular la de los 5 protones.

De todos modos es mi opinión personal de cómo me parece mejor usar la POO en C++ (será porque vengo del C).

No sé cual es el problema de los electrones y protones. Si lo propones lo veriamos. En cualquier caso ambos tienen carga q yo sepa y masa (aunq la de uno si no recuerdo mal es infinitamente más grande q la otra ¿o no era así?. De todos modos todos por ejemplo tendrían efecto electromagnético sobre los demás asi que no entiendo como quieres resolver el problema si no haces 1005*1005 / 2 calculos...

[shephiroth]

"un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros" acaso esto no es el enunciado perfecto de "funcion virtual y que hereden las hijas"?? Aclarate :wink:

Aclárame tú cómo hacerlo con una función virtual, por ejemplo: Necesito averiguar de la lista de vehículos en un momento dado, cuál es el que tiene el maletero más pequeño.

El problema de obtener el precio medio de los coches todavía creo que no ha sido resuelto sin usar el GetType

Sobre el maletero mas pequeño, depende para q lo necesites. Como puse en un post anterior quizas te interese tener mas de un contenedor para tus objetos. La idea de poder juntar en un contenedor clases hijas esta ahi, pero no es obligatorio juntarlas siempre.

Sobre el precio medio, yo me decantaría sobre una funcion statica en la clase hija y una lista dynamica...aunque lo puesto arriba aqui tambien opera...haberlas hay miles de formas usando poo, otra cosa es q nisiquiera intentes buscarlas.

Y en cuanto a los otros ejemplos en el que se da la solución de ir añadiendo más y más funciones virtuales (como comenta Fran),  ¿que pasa cuando no se puede modificar la clase base por la razón que sea?, por ejemplo porque solo tengas el C.Objeto, o porque el diseñador no le apetece que le meta mano todo programador que quiera resolver su problema puntual.

¿Y cuando se necesita iterar una cantidad exagerada de objetos como pudieran ser partículas por ejemplo para calcular la fuerza de gravedad que ejercen unas sobre otras?, olvídate de usar funciones virtuales.

Cuando solo tienes CObjeto, te creas tus bases intermedias CControl CListas CVehiculo CLoquetedelagana añadiendoles las funcionalidades que necesitas, y basandote en esas te creas tus hijas CCamion CMoto CBoton CListBox .....

Sobre cuando tienes un sistema de particulas...aparte de que no se mucho, yo no liaria herencia en un sistema....lo mas seguro crearia una clase base del sistema, y un sistema hijo con cada objeto q necesitase...y por supuesto las funciones virtuales SI aparecerian en los sistemas hijos.

Código [Seleccionar] Expand


Vehiculo{
.....
virtual getPlazoRevision(){result=4}
boolean getMeTocaLaRevision (dtFecha del tipo DateTime)
.....
}


Estas añadiendo esto para un problema puntual, pero ¿si te surjen mil problemas vas a añadir mil funciones virtuales?

Claro. Mil o 500 o 1500. Las q hagan falta.Todavia no conozco el programa que resuelva mil problemas sin programarlo.

Que gran verdad :)

[marcode]

No sé cual es el problema de los electrones y protones. Si lo propones lo veriamos. En cualquier caso ambos tienen carga q yo sepa y masa (aunq la de uno si no recuerdo mal es infinitamente más grande q la otra ¿o no era así?. De todos modos todos por ejemplo tendrían efecto electromagnético sobre los demás asi que no entiendo como quieres resolver el problema si no haces 1005*1005 / 2 calculos...

Aquí está el kit de la cuestión, si yo quiero reutilizar tus clases de partículas me estas obligando a calcular la atracción gravitatoria de los electrones porque sí tienen masa. Pero yo quiero en un momento determinado del programa despreciar la masa de los electrones porque son un 1/1.840 con respecto al proton, y no quiero hacer un millon de llamadas a funciones virtuales.

Quiero listas de punteros a los objetos que me interesen y a ser posible con funciones inline, es más, quiero listas de punteros a propiedades de algunos objetos, no entiendo porque debo ceñirme a una determinada metodología (por muy elegante que sea) si de algún modo estuviera perdiendo eficacia.

Creo que llevar a estos extremos la POO es encerrarlo todo en una caja muy bonita que puede que no le guste más que al que la diseño, espero no encontrarme nunca con una librería de una clase con 1000 funciones virtuales para cada uno de los problemas que se le hayan ocurrido que se pueden dar, y luego encima me tenga que volver loco para encontrar o hacer lo que yo quiero. Problemas que por lo general puedo resolver con 2 o 3 líneas y que no necesito incorporar a la clase. Entre otras cosas porque suelo crear otras clases que forman grupos donde guardo y reutilizo los problemas, en el caso de las partículas pudiera ser las clases Sistema Solar, Atomos, agua, humo, etc. Que tienen un comportamiento no sólo individual, si no colectivo. Me niego en rotundo a meter en la propia clase base de particulas todas las peculiaridades de todo lo que puedo considerar una partícula y sus diferentes aplicaciones, problemas, comportamientos o posibilidades que por mi parte dependiendo de casa situación y de cada programador pueden ser infinitas.

[shephiroth]

Buenas.

Me parece que estais liando mucho el rizo Marcode. En el ultimo post hablas de calidad, flexibilidad, reutilizacion de codigo.....y esto no depende de la metodologia utilizada, sino del codigo en si.

[Fran]

No sé cual es el problema de los electrones y protones. Si lo propones lo veriamos. En cualquier caso ambos tienen carga q yo sepa y masa (aunq la de uno si no recuerdo mal es infinitamente más grande q la otra ¿o no era así?. De todos modos todos por ejemplo tendrían efecto electromagnético sobre los demás asi que no entiendo como quieres resolver el problema si no haces 1005*1005 / 2 calculos...

Aquí está el kit de la cuestión, si yo quiero reutilizar tus clases de partículas me estas obligando a calcular la atracción gravitatoria de los electrones porque sí tienen masa. Pero yo quiero en un momento determinado del programa despreciar la masa de los electrones porque son un 1/1.840 con respecto al proton, y no quiero hacer un millon de llamadas a funciones virtuales.

Quiero listas de punteros a los objetos que me interesen y a ser posible con funciones inline, es más, quiero listas de punteros a propiedades de algunos objetos, no entiendo porque debo ceñirme a una determinada metodología (por muy elegante que sea) si de algún modo estuviera perdiendo eficacia.

Creo que llevar a estos extremos la POO es encerrarlo todo en una caja muy bonita que puede que no le guste más que al que la diseño, espero no encontrarme nunca con una librería de una clase con 1000 funciones virtuales para cada uno de los problemas que se le hayan ocurrido que se pueden dar, y luego encima me tenga que volver loco para encontrar o hacer lo que yo quiero. Problemas que por lo general puedo resolver con 2 o 3 líneas y que no necesito incorporar a la clase. Entre otras cosas porque suelo crear otras clases que forman grupos donde guardo y reutilizo los problemas, en el caso de las partículas pudiera ser las clases Sistema Solar, Atomos, agua, humo, etc. Que tienen un comportamiento no sólo individual, si no colectivo. Me niego en rotundo a meter en la propia clase base de particulas todas las peculiaridades de todo lo que puedo considerar una partícula y sus diferentes aplicaciones, problemas, comportamientos o posibilidades que por mi parte dependiendo de casa situación y de cada programador pueden ser infinitas.

Sinceramente el problema q expones tiene muchas soluciones evidentes desde el punto de vista de OOP que son muy efectivas y puedes plantear eso. Pero vamos, aquí nadie está obligando a usar OOP. Simplemente estabamos hablando de la ortodoxia de usar funciones virtuales vs RTTi y creo que eso no tiene discusion y de si se pueden solucionar prácticamente todos los casos sin recurrir a RTTi. Evidentemente para cualquier problema hay muchas soluciones y solo una es la óptima. Y ésta no tiene xq ser el uso sin excusas de la OOP pura. Creo que esa salida no tiene nada que ver con el tema del post.

[fiero]

Evidentemente para cualquier problema hay muchas soluciones y solo una es la óptima.

Creo que en programación no hay una "solución óptima". Y esa es la razón por la que este hilo tiene 9 páginas ya. Porque hay gente que se empeña en que sólo hay una forma óptima de hacer las cosas y no es así. Se puede optimizar el consumo de recursos, el tamaño del programa, la velocidad de ejecución, el tiempo de programación, la legibilidad del código fuente, la modularidad del código fuente, la rehusabilidad del código, etc, etc, etc.... Se puede optimizar para cada una de esas cosas, pero NO PARA TODO a la vez, por tanto, no existe una única manera óptima de hacer nada.

un saludo

[Fran]

Evidentemente para cualquier problema hay muchas soluciones y solo una es la óptima.

Creo que en programación no hay una "solución óptima". Y esa es la razón por la que este hilo tiene 9 páginas ya. Porque hay gente que se empeña en que sólo hay una forma óptima de hacer las cosas y no es así. Se puede optimizar el consumo de recursos, el tamaño del programa, la velocidad de ejecución, el tiempo de programación, la legibilidad del código fuente, la modularidad del código fuente, la rehusabilidad del código, etc, etc, etc.... Se puede optimizar para cada una de esas cosas, pero NO PARA TODO a la vez, por tanto, no existe una única manera óptima de hacer nada.

un saludo

No estoy de acuerdo. En todo, hay cosas muy buenas pero una de ellas es la mejor aunq sea por muy poco. Y eso no quiere decir q sea la mejor en todo. Quiere decir que comparando ventajas e inconvenientes y puntuando con criterios de empresa, es la mejor aunque en algunas cosas no lo sea. Esa es la óptima. Pero vamos no nos vamos a poner a eso ahora. En el caso que nos ocupa lo de las funciones viertuales lleva la mejor puntuación en mantenibilidad, legibilidad y ortodoxia. Es posible (habría q medirlo) que en velocidad no lo sea. El tamaño si no hablamos de diferencias de 100MB para arriba hoy para mi no es un criterio. Si además gana en velocidad pues no hay nada más q hablar y si no dependiendo de cada empresa posiblemente tb lo sea. En la mia lo es. El q corra un 10% menos es despreciable a cambio de que sea facil de mantener, legible y escalable

[Vicente]

Me hizo gracia encontrarme esto de casualidad leyendo sobre D:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD

Y que en el apartado OOP tengan:

- Dynamic class loading
- Reflection/Introspection

Ta claro que cada cual piensa lo que quiere :p Un saludo!

Vicente

[Fran]

Me hizo gracia encontrarme esto de casualidad leyendo sobre D:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD

Y que en el apartado OOP tengan:

- Dynamic class loading
- Reflection/Introspection

Ta claro que cada cual piensa lo que quiere :p Un saludo!

Vicente

Vicente. Te me escapas para variar  :lol:  :lol:  :lol:  :lol:  :lol:

[Vicente]

Como andábamos debatiendo de si RTTI es más o menos POO, pues me ha hecho gracia ver como dentro de características POO de lenguajes incluían la Reflexion.

En el Ave Fenix acabo de leer otro comentario que puede ser interesante sobre el tema:

http://www.elavefenix.net/Noticias06.aspx

Es la noticia de "Anders Hejlsberg rechaza el criticismo sobre C# 3.0". Supongo que se habrá criticado a los métodos extensionales: métodos que se añaden a una estructura o a una clase sellada (cosas que en teoría no se pueden modificar, porque de un struct no se puede heredar y una clase sellada, pues eso, es sellada :p).

Un saludo!

Vicente

[Fran]

Como andábamos debatiendo de si RTTI es más o menos POO, pues me ha hecho gracia ver como dentro de características POO de lenguajes incluían la Reflexion.

En el Ave Fenix acabo de leer otro comentario que puede ser interesante sobre el tema:

http://www.elavefenix.net/Noticias06.aspx

Es la noticia de "Anders Hejlsberg rechaza el criticismo sobre C# 3.0". Supongo que se habrá criticado a los métodos extensionales: métodos que se añaden a una estructura o a una clase sellada (cosas que en teoría no se pueden modificar, porque de un struct no se puede heredar y una clase sellada, pues eso, es sellada :p).

Un saludo!

Vicente

Lo he leido y sigo sin entender q tiene q ver. Por ciertlo, lo del equipo óptimo para Vista es de descojono

[Vicente]

Ya no tiene que ver tanto con lo de virtuales vacios vs RTTI, si no con lo que se ha comentado también de la "pureza" de la POO (RTTI es POO-- como decías tú, pues en esa línea).

Un saludo!

Vicente

[Fran]

Ya no tiene que ver tanto con lo de virtuales vacios vs RTTI, si no con lo que se ha comentado también de la "pureza" de la POO (RTTI es POO-- como decías tú, pues en esa línea).

Un saludo!

Vicente

Hombre. Vamos a ver. Si lo q quieres decirme es q RTTI está incluido , es cierto. Que se incluyó en contra de la opinión de los creadores de C++ y de muchos "puristas" x presiones de los programadores tb - Q es a lo q os referis Anders y tú, aunq él no habla de RTTi-. Q a mi no me parece ni mal ni bien. Tb. Pero q con lo q empezó el post fué con que RTTi era mejor y era OOP y crear funciones virtuales vacias no, creo q ha qdado demostrado que es más puro desde el p. de vista de OOP lo de las funciones virtuales aunq estén vacias y q no son ninguna patata. Pero q para gustos colores, estoy de acuerdo. Quien trabaje conmigo desde luego   tiene prohibido hacer cosas asi, pero no por nada, sino xq luego cualquier modificación necesita mil comprobaciones y modificaciones - no xq considere q no sea OOP pura, eso me da igual-

[marcode]

un momento, que va a opinar el especialista:

Si el problema consiste en averiguar el tipo exacto de todos los objetos, hay que volver a pensar porque posiblemente no se estén usando las funciones virtuales de forma apropiada. Sin embargo, hay algunas situaciones en las cuales el diseño funciona mejor (o no hay otra elección) si se conoce el tipo exacto de todos los objetos, por ejemplo aquellos incluidos en un contenedor genérico. Este es el problema de la runtime type identificatión o RTTI (identificación de tipos en tiempo de ejecucion).