Programacion Orientada al Objeto

On Wed, 18 Aug 2004 10:18:31 -0400, "Jose Luis Manners"
<josemanners(-arroba-)hotmail.com> wrote:

Creo que antes de comenzar tu proyecto deberias tratar de adquirir algunos
conocimientos básicos de POO y programación por capas (n-tier).

Y también algunos conocimientos sobre Sistemas de Bases de Datos.

La referencia estandar es: "Introduccion a los Sistemas de Bases de
Datos" de C. J. Date, mucho mejor que cualquier libro alternativo.

Sin entrar en muchos detalles, yo hice un módelo de objetos bastante BASICO
basado en lo que expones. No incluí las propiedades como Nombre, Ubicación,
etc. porque lo único que te quiero mostrar son los objetos y la relación
entre ellos :

Así se trabajaba en los años 50 y 60, manejando los datos directamente
desde las aplicaciones, con la única diferencia de que a los objetos
se les llamaba registros. Pero esta forma de trabajar quedó obsoleta
con la aparición de los Sistemas de Gestión de Bases de Datos.

Desgraciadamente este tipo de ejemplos siguen usandose para enseñar
POO, y esto hace que alguna gente pueda pensar que es una forma
razonable de trabajar con datos, cuando no lo es desde hace muchos
años.

Sería mejor enseñar POO con ejemplos que la utilizasen apropiadamente,
como por ejemplo en componentes gráficos o videojuegos.

Continente
PaisCollection
Pais
CiudadCollection
Ciudad
BarrioCollection
Barrio

Bueno primero tienes un objeto Continente el cual posee un objeto tipo
colección PaisCollection. PaisCollection contiene una lista de todos los
objetos tipo Pais para determinado Continente. Piensa en PaisCollection
como si fuera un ArrayList de objetos tipo Pais. Cada objeto Pais a su vez
contiene una colección CiudadCollection la cual es una lista de objetos
Ciudad que pertenecen a cada Pais.

A esto se le llama un modelo jerarquico. El Modelo Jerarquico quedó
obsoleto a principios de los 70 aunque todavía quedan muchos sistemas
heredados que utilizan SGBDes jerarquicos, sobre todo IMS.

Pero por supuesto que utilizar un modelo jerarquico para manejar datos
directamente desde la aplicación es algo mucho peor que utilizar el
arcaico IMS.

Ahora bien, en términos de base de datos yo creo que cada objeto individual
merecen estar en una tabla en la base de datos.

Una frase bastante ambigua. Claro que deben de estar en tablas, la
cuestión es como.

Asi que tendrias una tabla
aparte para Continentes, Paises, Ciudades, y Barrios las cuales deben estar
relacionadas en la forma en que estan relacionados los objetos (pero no
necesariamente).

La forma en que están "relacionadas" las tablas es radicalmente
distinta que en el modelo jerarquico.

En el Modelo Relacional las "relaciones" entre tuplas (filas) de
relaciones (tablas) distintas es una relación por valor y no a través
de un puntero como en el Modelo Jerarquico.

Para esto te sugiero leer sobre relaciones de padre/hijo
en bases de datos.

Yo he leido muchos libros serios sobre bases de datos y nunca me he
encontrado ese término. Se suelen llamar: restricciones de integridad
referencial.

Para crear los objetos desde las bases de datos te sugiero que leas bastante
sobre capas y patrones de diseño.

Los objetos ya están dentro de las bases de datos. La intersección
entre una fila (tupla) y una columna (atributo) en una tabla
(relación) es precisamente un objeto (valor) (entre parentesis están
los términos del mundo de las bases de datos).

No hay que crear nada, las tablas están llenas de objetos.

Con los llamados SGBD objeto-relacional como el nuevo SQL Server
Yukon, los objetos que podemos almacenar en las tablas ya no están
limitados a los tipos básicos predefinidos de SQL 92, sino que podemos
almacenar directamente cualquier objeto creado en cualquier lenguaje
.NET. Esto es un avance bastante importante.

La idea es que cuando en tu programa
quieras construir el objeto ContinenteCollection todas las dependecias sean
construidas a manera de cascada sin tu programa saber los detalles de como
se construyen.

Pero si tienes una tabla Continentes gestionada por el SGBD, ya no
necesitas para nada el objeto ContinenteCollection en la aplicación.

Los SGBD y el Modelo Relacional se crearon precisamente para eliminar
ese tipo de estructuras de las aplicaciones y simplificar enormemente
el desarrollo.

Un SGBD es un ejemplo perfecto de patrón de diseño, y de componente
reutilizable.

Patrón fundamental para los sistemas de información: Utilizar un SGBD
para gestionar los datos y utilizar una aplicación para presentar los
datos y interactuar con los usuarios.

Las aplicaciones son una interfaz entre los usuarios y el SGBD. Quien
debe de manejar los datos es el SGBD, por eso se llama así: Sistema de
Gestión de Bases de Datos.

Bueno espero no te haya confundido más en lugar de ayudarte. Te sugiero
nuevamente que leas bastante antes de comenzar.

El problema es que la mayoría de lo que se publica es de baja calidad,
sobre todo en el mundo de los objetos. Hay que tener bastante cuidado
y ser muy crítico con lo que se lee, de lo contrario podemos quedar
más confundidos que antes de empezar.


Un saludo

On Wed, 18 Aug 2004 13:55:26 -0500, "Víctor Rafael Bocanegra Arias"
wrote:

Alfredo en la actualidad hay DBMS que ya incluyen el manejo de objetos
dentro de la BD. Un ejemplo a esto seria PostGre

Lo que seguramente intentas decir es que hay DBMSes que permiten a los
usuarios definir nuevos tipos de objetos, como por ejemplo SQL Server
Yukon.

En bases de datos la POO se puede usar para crear nuevos tipos de
datos, pero para manejar los datos se sigue usando el calculo o el
algebra relacional.

Por ejemplo si antes queríamos crear una tabla de objetos "cuadrado"
no podíamos y ahora si podemos. Pero siempre hemos podido crear tablas
de objetos "Char" o "Numeric"

Estas nuevas tablas se manejan exactamente igual que las demás.


Saludos

On Wed, 18 Aug 2004 17:36:38 +0200, "Vyacheslav Popov"
wrote:

Hola Melissa,
yo vengo de Delphi y C++ Builder (Borland) y en mi opinión C# es totalmente
orientado a objetos y además el acceso a datos es mucho más amable.

La felosofía de tres capas de ADO.NET no es novedosa pero bastante
presentable.

Pues yo también vengo de Delphi (que tampoco es para echar cohetes), y
ADO.NET me ha parecido un gran paso atrás en facilidad de uso y
cantidad de código que hay que escribir.

Conozco a mucha gente que se resiste a pasar de ADO a ADO.NET por el
mismo motivo.

Saludos

On Thu, 19 Aug 2004 10:21:23 -0500, "Víctor Rafael Bocanegra Arias"
wrote:

Alfredo que tus comentarios estan "fuera de lugar".

El único comentario que está fuera de lugar es este que acabas de
hacer.

Comenzando que ADO .NET no tiene nada complicado para obtener,adicionar,
actualizar, etc informacion desde cualquier "fuente" de INFORMACION.

Te veo bastante perdido.

Ahora cuando dices que no queda mas remedio que usar SQL, me parece que
"nunca" has trabajado con BASES de DATOS.

He trabajado con muchas. ¿Que tienes que objetar a mi afirmación?

SQL es el STANDARD para el acceso
de informacion de la mayoria de DBMS.

Falso, no es un estandar para el acceso a la información, es un
lenguaje de bases de datos estandard. Como todo lenguaje de bases de
datos es al mismo tiempo un lenguaje de definición de datos DDL y un
lenguaje de MANIPULACION de datos DML. El DML a su vez permite
consultas (y no acceso) y actualizaciones de la base de datos.

Y en lo que respecta a controles

Nunca he hablado de controles gráficos, esto tampoco lo has entendido.


Saludos

On Wed, 18 Aug 2004 11:05:10 -0400, "knito" <knito~@~chile~.~com>
wrote:

A los que les interese...

http://www.programacion.com/articul...sistencia/

Un artículo realmente malo.

El problema de estas webs es que pocas veces tienen un control de
calidad razonable y publican casi cualquier cosa que les manden.

Saludos