🚀 go-pugleaf

>  Supongo que cuando dices que Kylix est� orientado a objetos te refieres a
> que permite
> crear clases e instancias de la clase u 'objetos' (que no es lo mismo,
esto
> es lo que
>  siempre critico en C++, pues la orientaci�n a objetos la provee el
> programador no el
> lenguaje, por medio de una arquitectura bien hecha, dividida en capas y
> m�dulos o plug-ins,
>  donde los recursos de uso frecuente se dise�an de forma que sean
f�cilmente
> accesibles por toda
> la aplicaci�n de forma transparente, haciendo de estos recursos los
> verdaderos 'objetos'.

Tienes raz�n, no por programar en C++ se hace un programa orientado a
objetos. Necesita la extrecha colaboraci�n del programador. Pero lo
contrario tampoco, no por programar orientado a objetos el lenguaje lo es;
necesitas que el lenguaje te de la protecci�n necesaria. Te digo esto por
que creo que todo programador de C (creo que tu lo eres),  programa
orientado a m�dulos, o a TAD, pero C no te da esas capacidades de
encapsulaci�n y ocultaci�n de la informaci�n. Y a ver quien le dice a un
programador que cuando hace un *.h no est� haciendo un m�dulo :-( (vease
Modula2 para autenticos M�dulos y TAD)

>  Para m�, C++/Java/Kylix... son lenguajes DESorientados a objetos).
>  Yo me atrever�a a decir que cualquier aplicaci�n realizada con StarOffice
> cumple mucho mejor
> el parad�gma de la programaci�n orientada a objetos que el 99'9% de los
> programas realizados con
> lenguajes supuestamente OOP.

La programaci�n orientada a objetos no la da el lenguaje en s�, si no la
forma de programar. Pero esto es como todo. Pero no me negar�s que C++ da
las capacidades, y protecci�n necesarias para que un programador programe
orientado a objetos. �Sabes el fallo de C++? Que acepte c�digo de C, y su
preprocesador. Si no lo aceptara, nadie pondr�a en duda que C++ es
totalmente orientado a objetos. Y adem�s de los m�s dif�ciles, lo cual le da
su potencia, al igual que le pasa a C. Es m�s en C++ no puedes hacer nada
sin una clase previa (usando s�lo POO), al contrario que en otros totalmente
orientados a objetos como Smalltalk, que si, ya que heredan siempre de la
clase principal Object.

> para entender mejor lo que est�s haciendo resulta que el c�digo est� hecho
> en C, lo cu�l
> pone en duda de nuevo la necesidad de utilizar un nuevo lenguaje como
> Pascal. Que narices, por qu�
> no Cobol 99. �Habe�s probado el Cobol99? Es cojonudo. No tiene nada que
> envidiar a C.
> Y el ADA. Es la leche. �Para qu� continuar utilizando C?

Los lenguajes que dices son orientados a modulos y TAD. Eleva bastante el
nivel de complejidad, (millones de l�neas de c�digo) y ver�s que es m�s
facil usar POO que esos lenguajes muy bien programados. Pero C no puede
desaparecer, por que hay mucha base de c�digo. Esta es la raz�n principal de
que C++ acepte c�digo C.

> > > - C++ NO es un lenguaje
> > > orientado a objetos por mucho que se repita tan b�rbara tonter�a y en
> > > la pr�ctica se ven aut�nticas chapuzas de gente que cree que por
> > > teclear la palabra class dentro del c�digo ya est� programando a
> > > objetos -,
> >
> > esto se debe a mala pr�xis y falta de formaci�n, no al lenguaje.
>
>  Exacto, pero el C++ (a mi modo de ver) fomenta la mala pr�xis de la que
t�
> hablas.
>  Un ejemplo t�pico: Se supone que el objetivo de la programaci�n orientada
a
> objetos
>  es la de encapsular el c�digo y sus complejidades. Es t�pico sin embargo
> ver clases
> en C++ que ocultan miembros que deber�an ser p�blicos (porque ser p�blico
es
> pecaminoso)

�miembros? supongo que te refieres a atributos �no?

> para luego modificarlos con m�todos setXXX/getXXX que adem�s son agrupados
> en
>  subclases contenidas dentro de la clase principal. Para mayor cachondeo
los

Esto se debe al paradigma de la POO, es decir no se debe permitir que se
toquen directamente los atributos, ya que la implementaci�n de estos puede
variar en un futuro, o que se necesite comprobar sus valores. P.ej. mes s�lo
acepta los valores del 1 al 12, y eso lo hacen los m�todos. No es nuevo pasa
tambi�n as� en los TAD.

> constructores/destructores est�n mal implementados y acaban colgando el
> programa con
> punteros nulos y todo para manipular un dato de tipo int o char*, con lo
que
> en vez de encapsular
> el c�digo y sus complejidades han creado un terremoto donde no hab�a
> problema alguno.

Me resulta muy raro, en una clase bien dise�ada nunca pasar�a.

> M�s a�n, una clase mal implementada lejos de encapsular la complejidad del
> c�digo lo �nico que
> hace es encapsular los errores y hacer todo mucho m�s dif�cil de depurar.

Claro si est� mal hecha que quieres. Lo mismo pasa en C o en otros
lenguajes.

> Menuda la gracia cuando despu�s de est�r toda una ma�ana intentando
> encontrar un error te das
> cuenta con una sesi�n de debugger que el constructor hab�a inicializado
mal
> la clase por cualquier
> tonter�a y el objeto no conten�a los datos que se supene deber�a de
> contener. Oohh!, que gran suerte
> tener constructores/destructores que automatizan el c�digo y facilitan la
> programaci�n.

Pues si, es una gran suerte, pero sigue sin ser nuevo hasta en C puedes
hacer lo mismo, de formas un tanto m�s complejas. Pero claro a todo el
c�digo no a cada objeto que uses. De todas formas si la clase est� mal
implementada es normal que pase eso. Pero lo primero que debe mirar un
programador son los constructores y destructores si existen, ya que son la
base en s� de la clase. Por lo tanto el fallo es tuyo al no mirarlos bien. Y
si tienen herencia los de las clases base, aunque si est�n bien hechas no
tienes ni que mirarlas.

Dime algo, �que problema tienes con C++? �que te ha hecho?

---------------------------------
jespejoYASABES@QUEHACERarrakis.es
�Sistemas Operativos? �Vis�tala!
http://www.arrakis.es/~jespejo
---------------------------------