C++ y POO

[Jare]

La POO se basa en llevar el problema a los dominios de la mente y no a los dominios de la codificación.

:shock: Eso no tiene ningun sentido, y el que "pretende" tener no es cierto.

[zupervaca]

Preguntar que cilindrada tiene un vehiculo es romper con la POO

Efectivamente, es lo que se lleva intentando explicar desde unas cuantas paginas, como dije anteriormente en este caso no queda mas "webs" que saber que tipo de objeto se esta tratando, pero este caso es imposible de encontrar en un proyecto real, sobre todo si tienes via libre para hacerlo como tu quieras.
Creo que el hilo no va a evolucionar mucho mas ya que ambos bandos tienen razon, por lo menos desde mi punto de vista, ademas si vierais el codigo final con el que se trabaja en una empresa no le dariais mucha importancia a esto :lol:

[marcode]

Yo creo que el ejercicio de sukhur es Programación Orientada a Objeto (uno solo).

[shephiroth]

Me parece asombroso que haya gente que siga pensando que RTTI es mejor que POO. Hay casos en los que RTTI es necesario (como ejemplo, los scripts q me deciais), pero no os empeñeis.

El ejercicio tal cual se puso no es que estuviera mal planteado, sino mal interpretado, y me explico. Si para lo unico q quiere los valores internos es para mostrarlos, es suficiente con que en la clase base haya una funcion virtual mostrar_reporte. Y nos olvidamos de rtti...un for y usar la virtual y a correr.

Respecto a algunos que os parece mal dejar funciones virtuales vacias, o poner funciones virtuales que solo utiliza una clase hija...y os parece bien una funcion virtual gettype que puede ser que nunca se use?? Me parece que es una idea un poco corta. Para que lo veais claro, se podrían utilizar los controles de un formulario. Anda que no hay eventos y eventos, cantidad de funciones virtuales que se dejan a expensas de que el usuario final pueda si quiere sobreescribir esos metodos y utilizarlos. A ver quien te dice a ti que aunque tu solo has usado esa funcion virtual en una clase hija, al futuro programador le viene de perlas y TODAS las hijas que crea utilizan dichas funciones.

No me quiero extender mas, e insisto RTTI sirve para lo q sirve, pero no es fundamental para POO, es necesario para lo q se necesita.

SALUDOS ^^

[jaure]

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.

Tu estudias en la EUPLA?

Porque solo conozco a unos que en España usen componet pascal

[Vicente]

Para que lo veais claro, se podrían utilizar los controles de un formulario. Anda que no hay eventos y eventos, cantidad de funciones virtuales que se dejan a expensas de que el usuario final pueda si quiere sobreescribir esos metodos y utilizarlos.

[OT]Si hablas de los eventos de .NET, no tienen nada que ver. Un evento es un "wrapper" sobre un delegado multicast, y un delegado es una declaración de un tipo. Nada de una función virtual vacia para sobreescribir...[/OT]

Un saludo!

Vicente

[Fran]

Me parece asombroso que haya gente que siga pensando que RTTI es mejor que POO. Hay casos en los que RTTI es necesario (como ejemplo, los scripts q me deciais), pero no os empeñeis.

El ejercicio tal cual se puso no es que estuviera mal planteado, sino mal interpretado, y me explico. Si para lo unico q quiere los valores internos es para mostrarlos, es suficiente con que en la clase base haya una funcion virtual mostrar_reporte. Y nos olvidamos de rtti...un for y usar la virtual y a correr.

Respecto a algunos que os parece mal dejar funciones virtuales vacias, o poner funciones virtuales que solo utiliza una clase hija...y os parece bien una funcion virtual gettype que puede ser que nunca se use?? Me parece que es una idea un poco corta. Para que lo veais claro, se podrían utilizar los controles de un formulario. Anda que no hay eventos y eventos, cantidad de funciones virtuales que se dejan a expensas de que el usuario final pueda si quiere sobreescribir esos metodos y utilizarlos. A ver quien te dice a ti que aunque tu solo has usado esa funcion virtual en una clase hija, al futuro programador le viene de perlas y TODAS las hijas que crea utilizan dichas funciones.

No me quiero extender mas, e insisto RTTI sirve para lo q sirve, pero no es fundamental para POO, es necesario para lo q se necesita.

SALUDOS ^^

Totalmente de acuerdo. En mi caso esta forma tan OOP de hacer las cosas   me ha salvado mil millones de veces el cuerpo en PROGRAMACION REAL Y PROFESIONAL. No en programitas de voy a intentar hacerme mi MMORPG. Siempre y cuando digo siempre quiero decir sin excepción hay comportamientos no previstos (estilo esto quiero q lo haga igual q aqui, se me ha olvidado una entidad q es igual q esta,.... etc ) por el cliente, que este tipo de cosas te ayudan a solventar de una manera transparente y sencilla sin tener que retocar todo el programa. Además como bien dices, por ejemplo los eventos vacios para si quieres meter algo imagino q a los detractores de hacer cosas asi , les tienen que chirriar. A mi la programación hecha así, aprovechando con miras amplias y no con miras cortas la OOP me parece lo mejor del mundo. Por cierto , habeis oido hablar alguna vez del principio abierto-cerrado de Meyer? Y del de sustitucion de Liskov?

El de abierto cerrado dice que se puede cambiar un módulo sin cambiarlo. La clave es la abstracción. Los cambios en un sistema se hacen por este principio siempre añadiendo código. No cambiándolo. Este es uno de los principios básicos de la OOP. Y cualquier sistema q no cumpla esto está mal diseñado.

http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm

El de Liskov dice q cualquier cosa (sobre todo métodos) en una clase q tenga q ser consciente de qué clase es para poder funcionar viola este principio. Es antiOOP.

Pues miradlos y decidme q principios violan el hacerlo como decimos y no con RTTI xq la solucion RTTI viola unos cuantos principios de teóricos de la OOP como esos.

Como veis yo sigo dando teoria aceptada por todo el mundo. A ver si variais y dais teoria y no poesia ni ejemplos sin sentido. Esto es un debate  teórico. Asi q si quereis seguir seamos serios y aportemos teoría y pruebas q contradigan no opiniones ni ejemplos enrevesados que al final derivan en q no me acuerdo de esto. Si alguien quiere darlos q los formule  q se entiendan con mirarlos. No sean estilo la parte contratante de la primera parte...

Saludos :lol:

[jaure]

Creo que hay tonos un poco salidos de madre, nadie aquí tiene que demostrar nada al otro en cuestión de si se es mejor o peor programador.

Un poco más de humildad no viene mal, el mundo sería mejor.

[Fran]

Creo que hay tonos un poco salidos de madre, nadie aquí tiene que demostrar nada al otro en cuestión de si se es mejor o peor programador.

Un poco más de humildad no viene mal, el mundo sería mejor.

¿? No creo q aquí se trate de demostrar nada acerca de lo peor o mejor programador que se sea. De hecho hay gente escribiendo aquí a la q considero buena programadora por los trabajos q he visto. Simplemente se ha establecido un debate teórico acerca de un tema, desde el lado del RTTI se "dispararon" dos sentencias al principio del hilo : eso es una patata, y eso no es OOP y me he cansado de escribir y de demostrar mediante teoría q no lo es y q además lo q no es OOP es la RTTI. Lo "gracioso" de esto es q tengo claro q la otra gente no va a cambiar ni a dar brazo a torcer ni yo voy a cambiar de manera de programar (xq además de q me ha dado durante 13 años muy buen resultado, tengo claro q estoy en estandares). Pero bueno. Como entretenimiento las "tertulias" estan muy bien. En cualquier caso si he ofendido a alguien, pido disculpas.

[Vicente]

Asi q si quereis seguir seamos serios y aportemos teoría y pruebas q contradigan no opiniones ni ejemplos enrevesados que al final derivan en q no me acuerdo de esto.

Me doy por aludido :p Te invito a que me corrijas el ejemplo si estaba mal (así refresco mi Java). Si no respondes supongo que estará bien...

Respecto a los eventos, ya os he dicho que en .NET no son funciones vacias, son declaraciones de tipos, como quien declara:

private int i;

Eso es un evento en .NET (más o menos, si os interesa http://www.codeproject.com/useritems/howeventswork.asp es una buena explicación). Así que no me chirria, porque no declaran una función virtual vacia para que sobreescriba alguien.

Un saludo!

Vicente

[Fran]

Asi q si quereis seguir seamos serios y aportemos teoría y pruebas q contradigan no opiniones ni ejemplos enrevesados que al final derivan en q no me acuerdo de esto.

Me doy por aludido :p Te invito a que me corrijas el ejemplo si estaba mal (así refresco mi Java). Si no respondes supongo que estará bien...

Respecto a los eventos, ya os he dicho que en .NET no son funciones vacias, son declaraciones de tipos, como quien declara:

private int i;

Eso es un evento en .NET (más o menos, si os interesa http://www.codeproject.com/useritems/howeventswork.asp es una buena explicación). Así que no me chirria, porque no declaran una función virtual vacia para que sobreescriba alguien.

Un saludo!

Vicente

El ejemplo "me se" escapa ... :lol: No entiendo que tiene q ver con esto. Y no digo q no tenga nada q ver, digo q no veo YO la conexión. Pero desde luego es un buen ejemplo del principio abierto cerrado. Lo poco q he visto de C# me gusta.En cuanto a Java ya te dije que no he visto a nadie declarar una sola clase para todos los eventos de todos los controles de una pantalla. Xq si tienes 100 controles
a) Es un chocho
b) Es dificil q no se puede reusar codigo de esa o de otras pantallas.

En su lugar  se declara o reutiliza clase por evento o bien si es q no te gusta eso ( a mí si xq te permite reutilizar) declaras un evento para cada tipo de control y despues los refieres por el nombre. No hace falta para nada el casting.

Y por cierto, no todo va a ser debate, cuando digo que sé de programadores en este hilo a los que considero buenos ( y tengo claro q lo q yo considere no vale para nada) me refiero especialmente a ti y a tu trabajo en Hadd. Creo q estais haciendo un gran trabajo.

[Vicente]

El ejemplo "me se" escapa ... :lol: No entiendo que tiene q ver con esto. Y no digo q no tenga nada q ver, digo q no veo YO la conexión. Pero desde luego es un buen ejemplo del principio abierto cerrado.

El ejemplo venía a que con lo que hablábamos de RTTI al principio de los vehículos, necesitas hacer un if (o un switch -> if (tipo = TIPO) then...), igual que si declararas todos los controles al mismo listener (donde para saber que control realmente usaste tendrás que hacer un switch por el nombre del control o algo así para diferenciarlos).

El manejador realmente puede estar en otro sitio, simplemente en ese switch se pone la llamada a la función. La cosa es que por como es Java (o por como yo recuerdo que Java funcionaba), 100 controles manejados a la forma "POO pura" serían 100 ficheros, 100 clases,... Con lo cual ya no tengo tan claro que sea la mejor solución (desde el punto de vista teórico sí, desde el punto de vista de implementación ni idea porque no programo en Java :p).

En su lugar  se declara o reutiliza clase por evento o bien si es q no te gusta eso ( a mí si xq te permite reutilizar) declaras un evento para cada tipo de control y despues los refieres por el nombre. No hace falta para nada el casting.

El if por el nombre es lo mismo que el if por el tipo, solo que por otra propiedad, pero estamos en las mismas, necesitas alguna forma de diferenciar algo.

Y por cierto, no todo va a ser debate, cuando digo que sé de programadores en este hilo a los que considero buenos ( y tengo claro q lo q yo considere no vale para nada) me refiero especialmente a ti y a tu trabajo en Hadd. Creo q estais haciendo un gran trabajo.

Gracias :) Ahora solo falta que lo use la gente :p

Pero bueno, está claro que para gustos colores, lo mismo en C++ se usan las funciones virtuales porque el lenguaje es más propenso a eso, y a mi que estoy en C# me choca muchísimo... Un saludo!

Vicente

[shephiroth]

Tu estudias en la EUPLA?
Porque solo conozco a unos que en España usen componet pascal

Es evidente que si...y no se si tomarmelo a bien o a mal ^^;

[OT]Si hablas de los eventos de .NET, no tienen nada que ver. Un evento es un "wrapper" sobre un delegado multicast, y un delegado es una declaración de un tipo. Nada de una función virtual vacia para sobreescribir...[/OT]

Totalmente cierto, pero hablamos de cosas diferentes. Los delegados son funciones miembros tipadas (espero haberme explicado). Me imagino que habras querido decir lo mismo con wrapper, pero esq no tengo ni idea de que es un wrapper...pero a lo que iva. No me refiero al las funciones que enlazas cuando creas un evento. Sino a todos los eventos PREDEFINIDOS en muchas clases .NET. Yo como utilizo winforms pues os hablo de lo que conozco, en MFC no se si rulara igual. En todos los controles (heredando de Control...q raro, verdad?? xDD) existen eventos predefinidos, que no tienes q tipar tu sino q estan ya creadas, y que la clase base se encarga de utilizar. Me estoy refiriendo a todas las funciones virtuales que empiezan por On.... Por ejemplo, si en vez de utilizar un ListBox, te creas una clase MiListBox, puedes utilizar la funcion OnChangeSelectedItem para recoger el evento SIN TENER QUE EXPECIFICARL EN NINGUN SITIO!!! Me referia a estas funciones virtuales.

Por cierto, q no son explusivas de los winforms. He trabajado un poco con sockets y las clases de sockets de .NET trabajan con los On. Seguro que .NET es mucho mas amplio y muchas mas clases utilizan este sistema.

El de Liskov dice q cualquier cosa (sobre todo métodos) en una clase q tenga q ser consciente de qué clase es para poder funcionar viola este principio. Es antiOOP.

Pues miradlos y decidme q principios violan el hacerlo como decimos y no con RTTI xq la solucion RTTI viola unos cuantos principios de teóricos de la OOP como esos.

Estoy deacuerdo en casi todo tu post, pero hay una cosa con la que no estoy deacuerdo. RTTI es util en algunos casos. Sobre que rtti viola principios teoricos de poo...cierto, los viola en las mayoria de los casos pero no en todos. Como dije en mi primer post (aunque en un tono desafortunado) hay mucha gente que se ha "mal-viciado" con su uso y ahora lo ven como una herramienta imprescindible, y ese es el error. Es util pero no imprescindible. Lo imprescindible es que disciernan entre "es una solucion" y "es la unica solucion", que no por llevarlo usando años significa que sea mejor (sino ande vamos a ir con el progreso xDD).

Creo que hay tonos un poco salidos de madre, nadie aquí tiene que demostrar nada al otro en cuestión de si se es mejor o peor programador.

Un poco más de humildad no viene mal, el mundo sería mejor.

¿? No creo q aquí se trate de demostrar nada acerca de lo peor o mejor programador que se sea. De hecho hay gente escribiendo aquí a la q considero buena programadora por los trabajos q he visto. Simplemente se ha establecido un debate teórico acerca de un tema, desde el lado del RTTI se "dispararon" dos sentencias al principio del hilo : eso es una patata, y eso no es OOP y me he cansado de escribir y de demostrar mediante teoría q no lo es y q además lo q no es OOP es la RTTI. Lo "gracioso" de esto es q tengo claro q la otra gente no va a cambiar ni a dar brazo a torcer ni yo voy a cambiar de manera de programar (xq además de q me ha dado durante 13 años muy buen resultado, tengo claro q estoy en estandares). Pero bueno. Como entretenimiento las "tertulias" estan muy bien. En cualquier caso si he ofendido a alguien, pido disculpas.

Para jaure, si lo dices por mi primera respuesta en el post tienes toda la razon, pero te pediria que leyeses todo el post, en la tercera o cuarta pagina me disculpe por eso mismo. Si no lo dices por ese post, estoy totalmente deacuerdo con vicente...se ha planteado un debate que es bastante interesante. Sobre que nadie llegue a entender al otro...creo que te equivocas. Yo estoy aprendiendo mucho. Sigo defendiendo que OOP es mucho mejor que RTTI, pero no por eso no estoy aprendiendo.

SALUDOS ^^

[jaure]

Tu estudias en la EUPLA?
Porque solo conozco a unos que en España usen componet pascal

Es evidente que si...y no se si tomarmelo a bien o a mal ^^;

[OT]Si hablas de los eventos de .NET, no tienen nada que ver. Un evento es un "wrapper" sobre un delegado multicast, y un delegado es una declaración de un tipo. Nada de una función virtual vacia para sobreescribir...[/OT]

Totalmente cierto, pero hablamos de cosas diferentes. Los delegados son funciones miembros tipadas (espero haberme explicado). Me imagino que habras querido decir lo mismo con wrapper, pero esq no tengo ni idea de que es un wrapper...pero a lo que iva. No me refiero al las funciones que enlazas cuando creas un evento. Sino a todos los eventos PREDEFINIDOS en muchas clases .NET. Yo como utilizo winforms pues os hablo de lo que conozco, en MFC no se si rulara igual. En todos los controles (heredando de Control...q raro, verdad?? xDD) existen eventos predefinidos, que no tienes q tipar tu sino q estan ya creadas, y que la clase base se encarga de utilizar. Me estoy refiriendo a todas las funciones virtuales que empiezan por On.... Por ejemplo, si en vez de utilizar un ListBox, te creas una clase MiListBox, puedes utilizar la funcion OnChangeSelectedItem para recoger el evento SIN TENER QUE EXPECIFICARL EN NINGUN SITIO!!! Me referia a estas funciones virtuales.

Por cierto, q no son explusivas de los winforms. He trabajado un poco con sockets y las clases de sockets de .NET trabajan con los On. Seguro que .NET es mucho mas amplio y muchas mas clases utilizan este sistema.

El de Liskov dice q cualquier cosa (sobre todo métodos) en una clase q tenga q ser consciente de qué clase es para poder funcionar viola este principio. Es antiOOP.

Pues miradlos y decidme q principios violan el hacerlo como decimos y no con RTTI xq la solucion RTTI viola unos cuantos principios de teóricos de la OOP como esos.

Estoy deacuerdo en casi todo tu post, pero hay una cosa con la que no estoy deacuerdo. RTTI es util en algunos casos. Sobre que rtti viola principios teoricos de poo...cierto, los viola en las mayoria de los casos pero no en todos. Como dije en mi primer post (aunque en un tono desafortunado) hay mucha gente que se ha "mal-viciado" con su uso y ahora lo ven como una herramienta imprescindible, y ese es el error. Es util pero no imprescindible. Lo imprescindible es que disciernan entre "es una solucion" y "es la unica solucion", que no por llevarlo usando años significa que sea mejor (sino ande vamos a ir con el progreso xDD).

Creo que hay tonos un poco salidos de madre, nadie aquí tiene que demostrar nada al otro en cuestión de si se es mejor o peor programador.

Un poco más de humildad no viene mal, el mundo sería mejor.

¿? No creo q aquí se trate de demostrar nada acerca de lo peor o mejor programador que se sea. De hecho hay gente escribiendo aquí a la q considero buena programadora por los trabajos q he visto. Simplemente se ha establecido un debate teórico acerca de un tema, desde el lado del RTTI se "dispararon" dos sentencias al principio del hilo : eso es una patata, y eso no es OOP y me he cansado de escribir y de demostrar mediante teoría q no lo es y q además lo q no es OOP es la RTTI. Lo "gracioso" de esto es q tengo claro q la otra gente no va a cambiar ni a dar brazo a torcer ni yo voy a cambiar de manera de programar (xq además de q me ha dado durante 13 años muy buen resultado, tengo claro q estoy en estandares). Pero bueno. Como entretenimiento las "tertulias" estan muy bien. En cualquier caso si he ofendido a alguien, pido disculpas.

Para jaure, si lo dices por mi primera respuesta en el post tienes toda la razon, pero te pediria que leyeses todo el post, en la tercera o cuarta pagina me disculpe por eso mismo. Si no lo dices por ese post, estoy totalmente deacuerdo con vicente...se ha planteado un debate que es bastante interesante. Sobre que nadie llegue a entender al otro...creo que te equivocas. Yo estoy aprendiendo mucho. Sigo defendiendo que OOP es mucho mejor que RTTI, pero no por eso no estoy aprendiendo.

SALUDOS ^^

Aquí, otro que ha ido allí, hace ya unos cuantos años, cuando empezo a hacerse algo con Java, pero mis prácticas de 1º eran integramente en component pascal y su blackbox (dios que quebraderos de cabeza...)

Hombre, a mal tampoco, hay mucho que raja de la EUPLA mal, yo hay cosas que no me gustaban, y sobre todo lo de los autobuses.

Me imagino que Falces seguirá por allí, y el de Sistemas lógicos, también tengo buenos recuerdos de ellos. Hay uno de Algebra que mejor no me lo encuentre por la calle.

Hombre no va para nadie concreto, solo que la discusión es interesante, y ver los argumentos de cada uno está bien, tengo claro que hay que usar ambas cosas dependiendo del caso, depende de lo que te quieras montar, hay veces que no merce la pena matarse mucho la cabeza, y otras es mejor hechar el resto y currarselo uno mucho para evitar luego quebraderos de cabeza ante posibles cambios.

Leí practicamente todo el post, y vi tus disculpas, solo es que en estos post enseguida se puede entrar en lo personal con comentarios que coloquialmente en persona no tienen trascendencia, pero escritos suele sonar todo más duro, o mal interpretarse.

Pero os aseguro que es interesante lo que decís, y que es verdad que de vez en cuando hay que repasar las bases de la POO, porque se cogen vicios del día a día, y de trabajar en proyectos que han sido programados y reprogramados 20 veces por diferentes personas, y hay que volver a los "origenes" de vez en cuando, para depurar estilo.

saludos

[Vicente]

Sino a todos los eventos PREDEFINIDOS en muchas clases .NET. Yo como utilizo winforms pues os hablo de lo que conozco, en MFC no se si rulara igual. En todos los controles (heredando de Control...q raro, verdad?? xDD) existen eventos predefinidos, que no tienes q tipar tu sino q estan ya creadas, y que la clase base se encarga de utilizar. Me estoy refiriendo a todas las funciones virtuales que empiezan por On.... Por ejemplo, si en vez de utilizar un ListBox, te creas una clase MiListBox, puedes utilizar la funcion OnChangeSelectedItem para recoger el evento SIN TENER QUE EXPECIFICARL EN NINGUN SITIO!!! Me referia a estas funciones virtuales.

Mmm, las funciones On no son eventos, lo que hacen es lanzar eventos (supongo que lo que harán es un if (Evento != null) Evento(e); pero tampoco me he puesto a desensamblar eso). Y no son métodos vacios (ya que hacen cosas).

Además, siguiendo con el tema, si te fijas, Control no define OnSelectedItemIndexChange (por ejemplo), si no que está definido a nivel de ListControl (la clase común para el ListBox y el ComboBox).

Esto es: en el framework de .NET, la función virtual OnSelectedItemIndexChange no está definida como vacía en Control y luego en ListControl ya se la sobreescribe con código. Está declarada directamente en ListControl, y si tienes un Control, no puedes acceder a ella sin un cast. No me meto en que sea mejor ni peor, simplemente digo que está hecho así.

Un saludo!

Vicente