🚀 go-pugleaf

"Victor M. Varela" wrote:
> 
> NAVARRO LOPEZ, Jes�s Manuel@nirgendwo dijo:
> 
> > > Para que ?
> > >
> > > Existe CORBA (para cualquier plataforma) pero en mi opinion la arquitectura
> > > de clientes distribuidos tiene mas inconvenientes que ventajas en
> > > cualquier sistema. Siempre es mejor quedarse en objetos normales.
> 
> > �Y eso por qu�?  A simple vista se dir�a que una tecnolog�a de objetos
> > distribuidos tiene muuuuuuchas ventajas...
> 
> Las ventajas se ven superadas por los inconvenientes. Por ejemplo, el
> exceso de capas de software (mas memoria menos velocidad) o los errores en
> la resolucion de dependencias entre estos componentes. Lo tipico que hace
> fallar a Windows.
> 

Es cierto que a�ade capas de software t�cnicamente innecesarias, cuando
se trabaja en local, pero a cambio, exactamente el mismo c�digo
funcionar� tanto en local como en remoto.  Sin embargo, es inexacta la
apreciaci�n que haces por lo que respecta a la resoluci�n de
dependencias.

> Respecto a las ventajas, solo puedo citar la facilidad de reutilizacion y
> la comparticion de recursos (pero eso tambien lo tienes con la
> programacion orientada a objeto tradicional)

Dos cosas: por un lado, hasta cierto punto est�s mezclando churras con
merinas, en el sentido de que est�s hablando por un lado de una
definici�n de arquitectura (objetos distribuidos), pero por otro lo
comparas con un modelo de programaci�n (OOP).  Sin embargo, es una
mezcla habitual porque normalmente se desarrollan los paradigmas
arquitect�nicos y de desarrollo de forma paralela.  Por otro lado (y yo
tambi�n voy a mezclar aqu� dise�o y programaci�n) lo que dices me parece
incorrecto: la programaci�n OOP tradicional se basa en enlaces en tiempo
de programaci�n que es, precisamente, lo que produce los problemas de
dependencias;  por el contrario, la misma esencia de la programaci�n de
objetos distribuidos est� en ligar la compatibilidad no al momento de la
programaci�n, sino a nivel binario, estableciendo la programaci�n con
herencia por interfaces, lo que justamente hace lo contrario de lo que
t� dices: asegurar *siempre* la compatibilidad entre objetos...  �C�mo
es que esto en la pr�ctica no ocurre? me preguntar�s entonces: pues
porque muchas veces se programa *mal*.  M�s de cuatro veces he visto
enlazar un componente a trav�s de una interfaz gen�rica (en Windows, no
he programado en Linux, pero las ideas son exactamente las mismas),
digamos SQLHandler, en lugar de con la versi�n concreta de la interfaz
de que se trate (en el ejemplo podr�a ser SQLHandler.1).  En tanto se
respete la definici�n de interfaz (y con definici�n con ajuste de
versi�n esto deber�a significar "siempre") y exista una definici�n IDL
para las plataformas del cliente y el servidor (la especificaci�n de
c�mo deber� ser el enlace a nivel binario), el resultado es que *nunca*
podr�s tener problemas de compatibilidad: simplemente la interfaz estar�
o no estar�, pero si est� no podr� ser otra que la que se defini� en su
momento...  Para conseguir el mismo efecto con OOP tradicional, deber�as
recompilar tanto los servidores como los clientes para la nueva versi�n
(�te suena tener que compilar t� por tu cuenta tal o cual paquete para
que funcione en tu equipo por culpa de versiones de librer�as, cuando en
realidad no hay tal incompatibilidad, puesto que la compilaci�n que
haces t� da como resultado un binario perfectamente funcional?) lo que
en cuanto hablemos de m�s de un par o tres de clientes es, normalmente,
inviable.
Respecto a la programaci�n utilizando interfaces, se suele decir (y es
cierto) que es un m�s trabajosa que la herencia habitual, precisamente
porque con la interfaz lo �nico que "heredas" es un contrato sobre unos
m�todos y/o par�metros, pero no el c�digo que hay o puede haber
"dentro".  A cambio, a menos que tengas una diagrama de clases
perfect�simamente definido y totalmente est�tico (lo que no ocurre
pr�cticamente nunca) el uso de interfaces trae a cuenta, precisamente,
por la compatibilidad que t� les negabas (y que hereda, por su forma de
ser, el dise�o mediante objetos distribuidos).

-- 
SALUD,
Jes�s
***
jesus_navarro@promofinarsa.es
***