From: "Alejandro F. Reimondo"
Date: Thu Jan 10, 2002 8:58 am
Subject: Re: [objetos] Consulta sobre implementacion en BD


Hola GermanA,


Esto que decis, sobre las necesidades de rediseño a medida
que escala el volumen lo conozco muy bien :-( por eso quería
saber si me podés ampliar un poco como se soluciona
con objetos (delegación).

Estoy seguro que habrás notado que, en Smalltalk los métodos
son cortos (cuando uno tiene un cierto dominio sobre como
trabajar con objetos).
La cantidad de mensajes por método son pequeñas (a menudo
no mas de 10; 3 a 5 renglones).

Muchos reconocemos esto como algo muy positivo desde
el punto de vista estético.
Pero pocos reflexionamos sobre este punto mas allá
de esa "sensación".
He visto que pocas personas tratan de entender un poco más
de que se trata o que genera esta forma de construir un
sistema (en pequeñas frases).

Incluso, es común escuchar razonamientos como "en smalltalk
se escribe lo mismo pero en métodos mas cortos"
o "podría hacer lo mismo en st que en el lenguaje XXX"...
No es verdad que en Smalltalk uno escribe lo mismo
pero en fracciones mas chicas; porque en realidad lo que
ocurre es que en Smalltalk se escribe menos.
Atención, no estoy diciendo que esto es "gracias" a smalltalk
como herramienta!, pues, el que uno escriba menos es una
consecuencia de una capacitación que uno realiza;
capacitación en el trabajo con objetos (en una forma de
pensar), que por cierto puede realizarse adecuadamente
solo utilizando un ambiente de objetos.

El escribir menos no es fácil. Pasan
varios meses hasta que uno empieza a dominar como
hacer para escribir poco (y aprender a leer mas que escribir []).

Pero... que relación tiene esto con la escalabilidad?

Es fácil ver esa diferencia en el tamaño de los métodos en Smalltalk.
Pero eso es un fin? o es una consecuencia de algo mas profundo?

Aprender a trabajar con objetos, es justamente eso...
aprender a armar objetos y hacerlos evolucionar mientras
"viven" (conforman un sistema orgánico y estable).
Trabajar con objetos NO es escribir código.
Si... usamos una sintaxis, debemos reconocer que esto
se debe a que hoy necesitamos una forma de "dialogar"
(enviar mensajes) con los objetos.
Pero nuestra tarea principal es de construcción, de armado.
A veces la construcción de una determinada maquinaria (engine)
es costosa y en esos casos armamos maquinas (frameworks)
que nos crean/instancian otras maquinas. Esto puede ocurrir
"durante el desarrollo" o en cualquier momento, ante la necesidad
de evolución del sistema.

En este marco es fundamental que la información este compuesta
de objetos, es decir, de datos+comportamiento COMO UNA UNIDAD;
este el objeto en un espacio temporario(RAM) o en un espacio
persistente. (no solo el comportamiento debe ser un objeto, sino
que además un objeto debe tener como carácter intrínseco/natural
su comportamiento).

Definiendo entonces un sistema, ya no como datos y programas(métodos)
que los manejan, sino como un conjunto de cosas; es que empiezan
a cambiar la forma adecuada para resolver algunas problemáticas.

El caso de la escalabilidad:
Es conocido que en la tecnología tradicional y orientada a objetos (separado
el lenguaje de los "objetos"), la escalabilidad presenta un problema
que se resuelve cambiando la parte programada (diseño/métodos).
En cambio si trabajas con objetos, todo se resuelve cambiando
UN OBJETO por otro.
(espero se entienda que al decir "un objeto" NO estoy diciendo
un objeto de clase método ;-)

A modo de ejemplo, si en un sistema tenes una colección de clientes
y esta colección posee 10 elementos; es lógico que se maneje con
un array; pero si esa colección es muuuuy grande e incluso distribuida...
es esto adecuado?
Claro que no, por el diseño que posee Array para resolver el problema.
Entonces lo que debemos hacer es cambiar esa colección (ese objeto)
por otro (polimorfico con Array []). NO debemos cambiar ningún método!

Lo mismo ocurre a gran escala, cuando uno trabaja a diario.
Pero seguramente te darás cuenta que para hacerlo el sistema
DEBE estar escrito de una manera muy particular (donde
lo que se escriba no te condicione a futuro).
Aprender Smalltalk es aprender a trabajar así (con objetos),
entre otras cosas.

hasta pronto,
Ale.
[] Fijense que esto NO reduce los tiempos, sino que solo
define actividades diferentes durante la construcción de
una solución. EL objetivo de escribir menos NO es ganar
tiempo (sino uno aprendería tipeado rápido antes que
a programar :-)
[] Fijate que el mismo objeto (u otro) puede darse cuenta que
ya no es tan conveniente y decidir mutar a otra especie
mientras funciona.



Original Message -----
From: "garduino"
To:
Sent: Tuesday, January 08, 2002 7:51 AM
Subject: Re: [objetos] Consulta sobre implementacion en BD



In smalltalking@y..., "Alejandro F. Reimondo"
wrote:

Además es común ver que los
sistemas relacionales requieren de rediseños a medida
que escala el volumen de información, problemática
ridícula en caso de utilizar objetos (delegación).


Hola Ale, Lista:

Me interesa mucho el tema de cómo guardar objetos y conocer las
desventajas de guardar objetos en bases relacionales.

Esto que decis, sobre las necesidades de rediseño a medida que escala
el volumen lo conozco muy bien :-( por eso quería saber si me podés
ampliar un poco como se soluciona con objetos (delegación).

Saludos.
 

ArSol.biz 2004