Últimos mensajes - Powered by IBM

Palabras claves

Entender las aplicaciones orientadas a Objetos

25/11/2006 - 20:21 por Javito | Informe spam

Hola a todos, después de varios meses estudiando la programación
orientada a objetos y sé programarla y entiendo todos los conceptos que
implican los objetos como herencia, encapsulación etc. pero hay varios
conceptos globales que no entiendo y que me encantaría que si alguien conoce
me orientara un poco.

Mis dudas son:
1) En una aplicación orientada a objetos ¿ El Servidor carga todos los
objetos que necesita la aplicación cuando se inicia la misma ?
2) ¿ Quiere esto decir que en estas aplicaciones no se accede a la Base de
Datos para realizar las operaciones, sino que se realizan sobre los objetos
en memoria ?
3) Si hay varios usuarios trabajando en la aplicación y cada uno carga sus
propios objetos desde datos de la Base de datos, si tu has hecho algo en un
objeto en memoria, el que se incorpora a la aplicación al cargar los datos
desde Base de datos no va a tener tus cambios y habría inconsistencia de
datos ¿ como se evita esto ?

Un saludo a todos y a ver si me podeis echar un cable.

Siga el debate

37 respuestas

Tengo una respuesta

Preguntas similare

Leer las respuestas

#11 Alfredo Novoa

27/11/2006 - 12:23 | Informe spam

Hola,

On Sun, 26 Nov 2006 19:48:13 +0100, "Alberto Poblacion"
wrote:

Comentame si para ti es así, o hay alguna cosa más que tener en cuenta

Efectivamente, esa es la idea de la orientación a objetos: El objeto
contiene los datos más los métodos que operan sobre dichos datos.

Y es un buen indicador de la falta de rigor de la OO, por que los
métodos no son parte de los objetos, son parte de las clases.

Saludos

Responder a este mensaje

#12 Roberto M. Oliva

27/11/2006 - 14:29 | Informe spam

Hola!

Yo creo que la verdadera potencia de la orientacion a objetos es cuando
te planteas la arquitectura de un programa en una vision mas alta. Como
todo esta inventado, solo hay que seguir los patrones de diseño.
Por ejemplo:
- Aplicar el MVC a toda la aplicacion mejora la robustez y la
testeabilidad de la misma.
- El polimorfismo ayuda, por lo menos, a hacer mas escalable la
aplicacion
- Para el ORM, tanto utilizando software de terceros (NHibernate, etc)
yo seguiria siempre el patron ActiveRecord.

Un saludo
Roberto M. Oliva

Alfredo Novoa ha escrito:

Hola,

On Sun, 26 Nov 2006 19:48:13 +0100, "Alberto Poblacion"
wrote:

>> Comentame si para ti es así, o hay alguna cosa más que tener en cuenta
>
> Efectivamente, esa es la idea de la orientación a objetos: El objeto
>contiene los datos más los métodos que operan sobre dichos datos.

Y es un buen indicador de la falta de rigor de la OO, por que los
métodos no son parte de los objetos, son parte de las clases.

Saludos

Responder a este mensaje

#13 Alfredo Novoa

27/11/2006 - 15:02 | Informe spam

Hola,

On 27 Nov 2006 05:29:35 -0800, "Roberto M. Oliva"
wrote:

Yo creo que la verdadera potencia de la orientacion a objetos es cuando
te planteas la arquitectura de un programa en una vision mas alta. Como
todo esta inventado, solo hay que seguir los patrones de diseño.

El problema es cuales seguir, como y cuando. Hay montones de patrones
que se usan cuando y como no se debe y también los hay obsoletos y
falsos.

Además los patrones no tienen absolutamente nada que ver con la OO.

- Aplicar el MVC a toda la aplicacion mejora la robustez y la
testeabilidad de la misma.

En un Sistema de Información el modelo sería el modelo de la base de
datos, la vista las aplicaciones de presentación y el controlador el
SGBD.

- El polimorfismo ayuda, por lo menos, a hacer mas escalable la
aplicacion

Entre otras muchas cosas. Pero en un Sistema de Información puede
haber muchas aplicaciones.

- Para el ORM, tanto utilizando software de terceros (NHibernate, etc)

Hibernate es un producto muy malo y el ORM no es un concepto bien
definido.

yo seguiria siempre el patron ActiveRecord.

El patrón ActiveRecord es tremendamente primitivo. Es mucho mejor
tratar los datos como conjuntos ("set at a time" en lugar de "row at a
time").

Saludos
Alfredo

Responder a este mensaje

#14 Alfredo Novoa

27/11/2006 - 15:17 | Informe spam

Hola,

On 27 Nov 2006 05:29:35 -0800, "Roberto M. Oliva"
wrote:

Yo creo que la verdadera potencia de la orientacion a objetos es cuando
te planteas la arquitectura de un programa en una vision mas alta.

La orientación a objetos te puede servir para plantear la arquitectura
de un programa, pero no sirve para plantear un Sistema de Información
completo. Para eso se necesita una visión mucho más amplia que englobe
la teoría de bases de datos y las técnicas de programación de
aplicaciones como la OO.

Saludos

Responder a este mensaje

#15 Roberto M. Oliva

28/11/2006 - 00:29 | Informe spam

Hola Alfredo!

De verdad piensas lo que escribes???

Además los patrones no tienen absolutamente nada que ver con la OO.

En la Wikipedia:
http://es.wikipedia.org/wiki/Patr%C...ise%C3%B1o

Todos los patrones se basan en diseños OO.
Sigo:

http://www.dofactory.com/Patterns/Patterns.aspx

En un Sistema de Información el modelo sería el modelo de la base de
datos, la vista las aplicaciones de presentación y el controlador el
SGBD.

Tu estas hablando de un sistema cliente-servidor de n-capas (bueno, 3
en tu caso). Te estas quedando en la arquitectura del sistema. Yo hablo
de la arquitectura del software.
Has probado a desarrollar utilizando un modelo MVC pasivo
(http://www.martinfowler.com/eaaDev/...creen.html) o con
Supervising Controller
(http://www.martinfowler.com/eaaDev/...enter.html)...
utilizas testeos (TDD: http://www.agiledata.org/essays/tdd.html) en el
software?

Entre otras muchas cosas. Pero en un Sistema de Información puede
haber muchas aplicaciones.

No se que tiene que ver con el polimorfismo. Yo hablo de lo siguiente:
http://www.martinfowler.com/article...ction.html

Hibernate es un producto muy malo y el ORM no es un concepto bien
definido.

>yo seguiria siempre el patron ActiveRecord.

El patrón ActiveRecord es tremendamente primitivo. Es mucho mejor
tratar los datos como conjuntos ("set at a time" en lugar de "row at a
time").

Date una vuelta por:
http://www.hibernate.org/
http://www.castleproject.org/
incluso por la pagina de Ruby on Rails (http://www.rubyonrails.org/) te
recuerdo que Rails utiliza ActiveRecord...
<modo_ironico>Si, todas estas paginas se las ve muy paradas. Hay muy
pocos programadores utilizando esto y se ve que se va a
abandonar</modo_ironico>

Bueno, tienes una vision muy particular de la programacion orientada a
objetos.
Saludos
Roberto M. Oliva

Alfredo Novoa ha escrito:

Hola,

On 27 Nov 2006 05:29:35 -0800, "Roberto M. Oliva"
wrote:

>Yo creo que la verdadera potencia de la orientacion a objetos es cuando
>te planteas la arquitectura de un programa en una vision mas alta. Como
>todo esta inventado, solo hay que seguir los patrones de diseño.

El problema es cuales seguir, como y cuando. Hay montones de patrones
que se usan cuando y como no se debe y también los hay obsoletos y
falsos.

Además los patrones no tienen absolutamente nada que ver con la OO.

>- Aplicar el MVC a toda la aplicacion mejora la robustez y la
>testeabilidad de la misma.

En un Sistema de Información el modelo sería el modelo de la base de
datos, la vista las aplicaciones de presentación y el controlador el
SGBD.

>- El polimorfismo ayuda, por lo menos, a hacer mas escalable la
>aplicacion

Entre otras muchas cosas. Pero en un Sistema de Información puede
haber muchas aplicaciones.

>- Para el ORM, tanto utilizando software de terceros (NHibernate, etc)

Hibernate es un producto muy malo y el ORM no es un concepto bien
definido.

>yo seguiria siempre el patron ActiveRecord.

El patrón ActiveRecord es tremendamente primitivo. Es mucho mejor
tratar los datos como conjuntos ("set at a time" en lugar de "row at a
time").

Saludos
Alfredo

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7 8

Busqueda sugerida