Comparando estructurado con POO

[Carxl]

Hola a todos, cómo van??

Pues como intento cambiar mi mentalidad de estructurada a POO, tengo algunas dudas teóricas y prácticas que me gustarían que me ayudaran a aclarar si es posible

Suponiendo que se requiere una DB para interactuar con un sistema(no importa el lenguaje, por ahora necesito es aclarar conceptos), pues necesitaríamos conectarnos, consultar, insertar, modificar, eliminar y todo lo que se requiera con la DB.

Para mi está claro que aparecen 5 operaciones (conectarnos, consultar, insertar, modificar, eliminar) y que debo realizarlas en cada módulo (hablemos que el sistema tiene el módulo de usuarios y perfiles).

En mi mundo estructurado, crearía un función conexion(), pasando como parámetros el host, el usuario y el password para utilizarla cuando requiera u otro manera de hacerlo (que es la que hago normalemente) sería de una vez en la función poner estos campos, pues para no estar pasándolos como parámetros y utilizarla directamente.

Las otras 4 operaciones (consultar, insertar, modificar, eliminar) las realizo en cada módulo dependiendo de lo que se necesite.

De esa manera programaría mi sitio y es como lo hago estrucuradamente, ahora mi dudas son:

1- Como se representaría ese problema en POO?? Cuáles son los objetos??
2- Los métodos en POO son las 5 operaciones que nombré??
3. Se haría una clase para esto?? O varias clases??



Espero me hayan entendido, y porfa no sean tan técnicos en responderme que apenas voy en el primer paso

Saludos y gracias de antemano

[guille_el3]

A ver que podemos rescatar...
Tenemos 5 operaciones y queremos saber a que objeto/s pedirle que las realice.

Podriamos bien por el momento tener un objeto "base de datos" que le digamos ejecutaQuery( unQuery).

y ese query pueda ser un insert, un delete, un update... etc.

Ese objeto cuando lo creas se supone que ya tiene todos los datos para conectarse a la base de datos y te abstrae de abrir/cerrar conexiones entre cada query.

Ahora... parece que quieres ser más específico y decirle a tu objeto inserta(esto), borra(estoOtro).

A partir de eso deberias pensar que necesita tu objeto base de datos para realizar cada operacion.
Quizas te conviene pensar que tendras un objeto manejador de usuarios, que le diras "inserta( uncliente )" y le pasas un objeto cliente como parámetro... y el adentro hablará con el objeto base de datos y hará un insert derecho...

Cosas a pensar:
1) en algun lugar el "insert into tabla values (...)" lo vas a tener que tener.
2) Todo esto lo dije tirando ideas al aire y sin saber exactamente tu problema o porque quieres hacer esto....
3) hay cosas como estas hechas, como es hibernate, y usan archivos XML y reflection para hacerlo suuuper configurable, podrias averiguar algo de eso o ver si te sirve en vez de hacerlo todo de 0.

Nada... Espero que sirva algo lo que dije, suerte!

[Carxl]

Hola guille_el3, cómo vas??

Man gracias por responder!!

Mmmm pues respecto a lo que me dices que por que quiero hacer esto, era solo un ejemplo que quería mirar, y para ver como lo plantea la gente que sabe POO...

Gracias por tu aclaración Estuvo del putas!!!

Ahora, bien(sigo con mis preguntas ojalá no moleste), suponiendo que quiero hacer una tienda virtual (productos, categorias, subcategorias). Donde cada producto dependiendo de la subcategoría tiene descripciones y atributos diferentes (los automóviles al igual que los muebles son productos, pero tiene lógicamente atributos diferentes)... Sabiendo que una categoría contiene x categorías y que las subcategorías contienen los productos...Cómo sería ahí la lógica POO??

A veces pienso en POO, de cierta manera, como si fueran las tablas de una DB relacional (la tabla productos, la tabla categorías y la tabla subcategorías) pero que serían los objetos(el objeto producto, el objeto categoría y el objeto subcategoría) Estoy bien?? Y pues pienso que podrían salir otros objetos, como la relación categoría-subcategoría, la relacion subcategoría-producto... Si puede ser así???

Gracias de antemano!!!

[guille_el3]

Uhhh, te metiste en un problema muy filosófico =P. Hay gente que prefiere diseñar antes el "modelo de datos", o sea la base y luego hacer una tabla para cada clase o tipo de objeto que tenga.
Otros sin embargo prefieren tener todo un modelo de objetos andando, que se sepa que funciona bien y luego hacer la base de datos a partir del modelo.

De la manera 1) normalmente tus objetos terminan solo conteniendo datos (value objects) y hay un objeto "programa" o "sistema" que hace todo. Y eso no es programar orientado a objetos lamento decirlo :P.

De la manera 2) que es la que quizas más me gusta, puede que se complique un poco mas encontrar la relacion entre tus objetos y las tablas de la BD, pero tienes un sistema orientado a objetos, probablemente más robusto y que expresa mejor el problema y lo resuelve de una manera más natural/sencilla/flexible/linda =P.

Si debes hacer algo como categorias/subcategorias lo más común es que debas utilizar un composite (busca composite + design patterns o patrones de diseño en google o wikipedia). El composite explica una forma simple de tener objetos simples y compuestos y tratarlos de la misma manera, que es lo que entiendo que quieres hacer tu, hablar con categorias y subcategorias(que a su vez tienen subcategorias :P)...
Bueno puedo pasarme horas hablando de cosas raras, pero me parece que lo mejor es que encuentres tu solución, probarla, que funcione y nada...

Con respecto a como hacer el juego de categorias, subcategorias y productos, es dificil decirlo porque no se bien que tienes que hacer, pero me parece que lo más correcto no es que las subcategorias conozcan a los productos, sino que los productos conozcan a su categoria para poder preguntarle cosas...

La premisa en objetos, la papa digamos está en preguntarse que objetos participan y que hay que decirle a ellos.
Por ejemplo, si tienes categorias y productos, y quieres saber el precio de un producto, lo más razonable seria que le pidas el precio al producto, no a la categoria. Idem con el total a facturar de un cliente. No se lo pediría a la empresa, se lo pediría al cliente que es quien debería conocer todos sus gastos...

Creo que me fui por las ramas.

[Carxl]

Hola de nuevo guille_el3, interesantes tus respuestas

Es que creo que mi problema por ahora es ese, saber identificar los objetos de un sistema Es que para mi todo son funciones y procesos jeje Pero guille, estoy mal al decir que esos son los objetos "obvios"(el objeto producto, el objeto categoría y el objeto subcategoría) del sistema?? o sigo interpretando mal??

Respecto a lo que me dices de la idea de este sistema, es, un producto debe estar contenido en una subcategoría siempre, pero una subcategoría debe estar contenida en una categoría siempre. Osea, para que exista un producto, debe existir una subcategoría, pero para que exista esa subcategoría, debe existir una categoría... me entiendes?? Mas o menos así:

Categoría -> Subcategoría -> Producto

Va relacionado de esa manera... no sé si fuí claro man

Ya estoy leyendo lo que me dijiste,

Saludos

[SidP]

POO implica entre muchas otras cosas aprender a identificar las clases presentes en tu problema así como las relaciones que se establecen entre ellas...muy util ademas es ir recogiendo toda esa información en un diagrama(diagrama de clases) bien organizado el cual te servirá como guía para utilizar con efectividad las clases....ahora estas pueden tener diferentes tipos de responsabilidades de ahi que existan diferentes variedades de clases atendiendo a su funcionalidad
ejemplo : entidad, controladora, interfaz,auxiliares
entre todas ellas existen las relaciones(es-un, tiene-un)
de aqui es donde surge las formas de representar estas relaciones con su multiplicidad
tiene-un(agregación,composición)
ejemplo: Almacen y Piezas
Almacen tiene-un Piezas o Piezas es-parte-de Almacen
cuando la relacion es de composicion o agregacion y su multiplicidad es de 1 a muchos la clase Almacen va a contener un arreglo de Piezas, al contrario cuando la relacion va de 1 a 1 Almacen solo contendra un objeto Piezas

el otro tipo de relacion es-un y aqui es donde entra a jugar su papel la Herencia con todo lo que lleva consigo la misma(clases Padre-Hijas) donde las hijas heredan todos los atributos y metodos de la clase Padre etc, etc, etc
ejem: Perro es-un Animal
Circulo es-una Figura

espero que esto te haya dado al menos una vaga idea para tu ejemplo

Salu2

[guille_el3]

Iniciado por SidP

POO implica entre muchas otras cosas aprender a identificar las clases presentes en tu problema así como las relaciones que se establecen entre ellas...muy util ademas es ir recogiendo toda esa información en un diagrama(diagrama de clases) bien organizado el cual te servirá como guía para utilizar con efectividad las clases....ahora estas pueden tener diferentes tipos de responsabilidades de ahi que existan diferentes variedades de clases atendiendo a su funcionalidad
ejemplo : entidad, controladora, interfaz,auxiliares
entre todas ellas existen las relaciones(es-un, tiene-un)
de aqui es donde surge las formas de representar estas relaciones con su multiplicidad
tiene-un(agregación,composición)
ejemplo: Almacen y Piezas
Almacen tiene-un Piezas o Piezas es-parte-de Almacen
cuando la relacion es de composicion o agregacion y su multiplicidad es de 1 a muchos la clase Almacen va a contener un arreglo de Piezas, al contrario cuando la relacion va de 1 a 1 Almacen solo contendra un objeto Piezas

el otro tipo de relacion es-un y aqui es donde entra a jugar su papel la Herencia con todo lo que lleva consigo la misma(clases Padre-Hijas) donde las hijas heredan todos los atributos y metodos de la clase Padre etc, etc, etc
ejem: Perro es-un Animal
Circulo es-una Figura

espero que esto te haya dado al menos una vaga idea para tu ejemplo

Salu2

Disculpa, pero no estoy de acuerdo del todo con eso que dices. POO es programacion orientada a objetos, y la unidad mas importante es el objeto, no la clase. Sino se llamaría programación orientada a las clases :P.

La clase es solo un mecanismo para crear objetos. Hay otros mecanismos como es el prototipado (que sin ir mas lejos utiliza javascript). Es más, en lenguajes "puristas" las clases son objetos como cualquier otro, donde su clase es una "metaclase" (que tambien es un objeto :P)...

Concuerdo en lo de las relaciones, pero tengo para acotar un par de cosas:
1) las relaciones son entre objetos, no entre clases.
2) esas relaciones pueden modelarse en diagramas de clases o de colaboración(donde se ven objetos, no clases), pero no es algo necesario. Los diagramas son una forma de comunicar ideas, expresar un modelo o diseño...
3) la relación de herencia debe tomarse con pinzas en diseños complejos porque podria no calzar bien en todas las situaciones, aunque en programadores/desarrolladores con poca experiencia puede que sea lo más natural e intuitivo.

[SidP]

Ciertamente.....a lo mejor no acote debidamente...gracias por la aclaración....por supuesto que el objeto es lo principal en POO de ahi su nombre...solo hice referencia a algunos temas importantes(clases,herencias) por eso dije

implica entre muchas otras cosa

e hice referencia a las clases y su respectivo diagrama ...por su importancia tambien...

Definición teórica: La clase es un modelo o prototipo que define las variables y métodos comunes a todos los objetos de cierta clase. También se puede decir que una clase es una plantilla genérica para un conjunto de objetos de similares características.

personalmente utilizo metodologías de desarrollo y en el tiempo de vida de un software una de las etapas mas importante es un buen modelamiento visual ya que es la clave para realizar el análisis OO....pues todo el trabajo posterior de implementación se basa en este diseño por lo que tiempo que se invierta en su elaboración es tiempo invertido en reusabilidad,claridad del codigo, encapsulamiento, etc...de ahi la importancia de un buen diagrama con toda la información

esas relaciones pueden modelarse en diagramas de clases o de colaboración(donde se ven objetos, no clases), pero no es algo necesario. Los diagramas son una forma de comunicar ideas, expresar un modelo o diseño...

mi hulmilde opinion a la hora de desarrollar es que POO requiere de una metodología que integre el proceso de desarrollo y un lenguaje de modelamiento con herramientas y técnicas adecuadas...de ahi que no lo vea como que no es algo necesario....

se podrían tratar temas importante en la POO como el envio de mensajes..en fin es un tema por donde cortar...


Muchos Saludos

[Carxl]

Hola SidP, guille_el3

Muchas gracias a ambos por responder... trato de absorver lo que me dicen, pero la gracia es hacerlo es entendiendo jejeje Ahí voy...

Ahora ando mirando la teoría básica de POO, mirando conceptos, ideas de otros autores, mirando ejemplos... Creo que eso no se aprende de un momento a otro.

La conclusión que saco de este post, es que saber analizar OO es una ·$%$f*%$& . Mas que saber programar OO lo importante es saber analizar OO, creo que esa es la base de esto. Podrás programar del putas, pero si no anailizas como es debido...

Llegué a este racionamieto por lo que me respondía guille_el3:

Todo esto lo dije tirando ideas al aire y sin saber exactamente tu problema o porque quieres hacer esto...

Con respecto a como hacer el juego de categorias, subcategorias y productos, es dificil decirlo porque no se bien que tienes que hacer.

Nunca me dijo exactamente cuales eran los objetos, puesto que(creo que yo que por eso lo hizo), un análisis OO es profundo y un poco complejo, no es ir tirando objetos por ahí y armando método y procesos... Quizás en un análisis superficial encontremos 5 objetos en un sistema, pero si lo analizamos con mas cuidado y detenimiento salgan mas o menos de lo inicial. Esto puede ser no?? Digan que sí!!! para decir que voy entendiendo.

Creo que ese es el reto, aprender analizar OO, mas que programar OO... además, si entiendo un análisis, podré intentar programar. No??

Saludos a los dos

[SidP]

Hola Carxl

desde mis inicios en el mundo de la programación e utilizado POO(Java..PHP en tiempo libre despues que reescribieran el core) y desde mi punto de vista los 3 conceptos fundamentales para entender la POO
* Encapsulamiento
* Herencia
* Polimorfismo

Mas que saber programar OO lo importante es saber analizar OO

se tiende mucho por estos tiempo a saber mucho de sintaxis pero en realidad se desconode que son los objetos....por eso entre programador y desarrollador hay una gran diferencia...por eso pienso que antes de ponerse a escribir codigo hay que conocer por lo menos los conceptos básicos de la POO
http://es.wikipedia.org/wiki/Program..._fundamentales

Un Saludo

[Carxl]

Hola de nuevo SidP, cómo vas?? Gracias por responder

Los conceptos que me muestras son lo que siempre he visto cuando intento estudiar POO y me parecen que son imprescindibles y necesarios...

Por ahora mas que aprender estos conceptos(ya me los sé de memoria), me interesa es "resetear" mi mente estructurada e inicilizarla en OO, llevo casi 7 años programando estructurado, pero quiero dejarlo y mirar hacia adelante.

No sè que tenga que hacer para lograrlo, no sé si con ejercicios o con mas lectura, pero vaya que ni he podido arrancar con mi primer análisis, me parece que todo lo que pienso, tiene estructurado "escondido"... Todo eso de patrones de diseño, de UML, de modelos vista controlador, todo eso me parte!!

En estructurado... creo una función.. un proceso... y sale

Pero acá al parecer, para hacer un proceso tengo que tener en cuenta muchas cosas Si hacer una clase, si hereda, si tienes métodos set, get, si cumple con polimorfismo, si tiene una buena abstracción... bueno.. un montonón de cosas, que teóricamente no le veo problema, pero ya cuando intento analizar no sé por donde empezar

Saludos

[guille_el3]

Es que intentas tener en cuenta muchas cosas desde el principio. Puedes saber la teoría, pero si no sabes aplicarla en un simple ejercicio, es dificil que salga.

Vamos a un dominio sencillo como el que planteabas antes. Tienes categorias, con subcategorias. Y productos para cada subcategoria.

Podriamos empezar a poner esos objetos. Pero ¿Realmente son necesarios? A mi me gusta definir a un objeto como "un ente que exhibe comportamiento", o siendo mas bruto "una cosa que hace cosas".

Entonces, si tengo objetos que no hacen nada, no son objetos! XD (Es algo discutible, pero es una buena forma de empezar)
Entonces para saber que deben hacer nuestros objetos, vamos a ver que queremos de nuestro programa.

Entonces suponte que nuestro programa es para hacer estadísticas, y queremos en un principio calcular estas dos cosas:

1) el precio de un producto.
2) todos los productos de una determinada característica.

Suponte que el precio del producto depende de su subcategoria...

Entonces la pregunta para empezar es ¿Que objetos participan y que mensajes les debo enviar para que me digan lo que quiero?

1) el precio de un producto es obvio que debo preguntárselo al producto, y escrito en sintaxis estilo c++, java seria...

Código:

unProducto.precio();

2) si queremos los productos de una característica, debería de pedírselos a la característica, de esta manera:

Código:

unaCaracteristica.productos();

Podrias complicarte poniendo get, set, pero eso no es realmente importante, son solo convenciones. Lo importante es: objeto -> mensaje

Ahora, ¿como hace el producto para responderme su precio?

Código:

#Producto
>> public double precio(){
  return categoria.precioProducto();
}

Ahi alguien podria decir que el precio lo tiene la categoría y hubiese sido mejor pedirselo a la categoria, de esta manera:

Código:

unProducto.dameTuCategoria().precioProducto();

O lo que es peor:

objetoMundo.dameCategoriaDe(unProducto).precio();

Ahi tienes 3 ejemplos de código. En uno le pides el precio al producto (pues lo que quieres es el precio del producto. El se lo preguntará a su categoría, pero a ti no te interesa como lo haga. De esa manera, es más fácil el dia de mañana cambiar la forma en que los productos calculan su precio, pero desde afuera no te enteras, pues le sigues preguntando producto.precio() :).

Para el segundo punto seria algo parecido

Código:

#Categoria
public Collection<Producto> getProductos(){

  Collection<Producto> productos; // Declaro una variable auxiliar

  foreach(SubCategoria subcategoria in subcategorias)
      productos.addAll( subcategoria.productos() );  

//Le pido a cada subcategoria sus productos y los agrego en la coleccion

  return productos;
}

#Subcategoria
public collection<Producto> productos(){
  return productos;
// a quien me pida mis productos le retorno mi coleccion de productos
}

Conste que los comentarios son a modo ilustrativo, jaja. Y con el numeral identifico a las clases...

Bueno, espero que la explicacion esta simple sirva para empezar algo...
Suerte!

[Carxl]

Hola guille_el3, cómo vas?? Gracias por el ejemplo

Mmmmmmmmmmmmmm según tu análisis y ejemplo, tengo una duda:

Me dices que un un objeto es "un ente que exhibe comportamiento" (no sé donde había leído eso antes jeje), entonces si redondeamos la idea de categorías, subcategorías y productos que diste... cómo identifico que ese ente tiene comportamiento??

En los ejemplos que pusiste todo va sobre el producto, para mi, ese sería un objeto, por que con él se realizan las consultas y las búsquedas...

Categorías y subcategorías no serían objetos no?? Para mi no hacen nada...

Cogí la idea?

Saludos man

[guille_el3]

No tienes mal la idea... El tema es que el precio depende de la subcategoría. Entonces digamos que el comportamiento de la subcategoria no te lo expone a tu, pero se lo expone al producto. Una palabra muy interesante en Objetos es "responsabilidad".
La responsabilidad de un objeto es el comportamiento que este debe exhibir (no solo a ti, sino a otros objetos).

Para el punto 1)
La responsabilidad de los productos es decirte su precio.
La responsabilidad de las subcategorias es decirle al producto su precio.

Para el punto 2)
La responsabilidad de las categorias es decirte cuales son sus productos.
La responsabilidad de las subcategorias es decirle a la categoria los productos.

O sea... un programa en objetos es un conjunto de objetos que hacen pequeñas cosas y se relacionan entre ellos para conseguir un objetivo más grande...

Lo importante es que intentes practicar lo básico en ejercicios cada vez mas grandes... Pero obviamente con una guia... sino no es simple saber si lo que haces esta bien o mal...

Con respecto a la duda que había surgido antes

Mas que saber programar OO lo importante es saber analizar OO

Mi respuesta es que programar en objetos es analizar un problema y ver que objetos hay ahi, por lo tanto no solo lo que dijiste es cierto, sino que es lo mismo!! Programar en objetos es analizar objetos.

Pero trata de no encarar los problemas con todo dede un principio, no hace falta que pienses en herencia o polimorfismo desde un principio. No pienses en interfaces ni clases, ni en encapsulamiento.
Piensa en objetos que deben hacer un pequeño trabajo cada uno y entre todos llegan a una solución.
¡Y ten cuidado con asignar mal las responsabilidades! Es importante que empieces a fijarte que le toca hacer a cada uno, y no darle responsabilidades de más ni de menos...

[Carxl]

Hola de nuevo guille_el3, cómo vas?

Gracias por el seguimiento que haz tenido en el post man

Sí, veo que estoy intentando tener en cuenta muchas cosas Haber si dejo tanta complejidad de un lado...

Ahí poco a poco me voy aclarando

Saludos man, de nuevo gracias