POO con VB.net

gracias por la aportacion, siempre se aprende algo.


Jandro

Jorge Serrano [MVP VB] wrote:

Bueno, técnicamente VB6 no era (y no es) un lenguaje de POO.

El trabajo con clases y atributos sí es una regla de POO y su uso en VB6
está limitado.
Digamos que en VB.NET tienes la posibilidad de trabajar con un lenguaje puro
Orientado a Objetos, algo que VB6 no lo era.
Eso te da la posibilidad no sólo de trabajar con clases de una forma más
amplia a lo que lo hacía VB6 y por supuesto, usar y aprovechar todas las
características que te ofrece un lenguaje de POO.

Aún así, en el caso de la duda planteada, quizás el paso de VB6 a VB.NET no
esté justificado. Hoy día hay muchísimas aplicaciones desarrolladas en VB que
siguen manteniéndose y ejecutándose sin problemas. El paso a .NET debe estar
meditado y justificado.
No se cuales son las características del desarrollo en cuestión que tratamos
en este hilo, pero igual no es necesario apostar por el cambio.

Un saludo,

Jorge Serrano Pérez
MVP VB.NET




"Jandro Casanovas" wrote:

no usabas clases en VB6??

pos eso era POO, rudimentario, pero POO.

Saludos!

SAM wrote:

Hola muchachos, tengo una consultilla para hacerles:
Soy nuevo en esto del .net y del POO pero no del VB6 el tema es, de que
manera puede facilitarme las cosas usando POO? por ejemplo tengo que hacer un
form de ABM de clientes, creo la clase clientes y le doy sus atributos, pero
despues como juego con el objeto? o sea no alcanzo a ver que utilidad puede
llegar a tener usando POO de la manera en lo que lo hacia con VB6, se
entiende?

Muchas Gracias

En mi opinión, no es una buena idea crear clases que se correspondan con las
tablas de una base de datos. En su lugar creo que es preferible usar
datasets con tipo.

Saludos:

Jesús López
MVP


"SAM" escribió en el mensaje
news:

Hola muchachos, tengo una consultilla para hacerles:
Soy nuevo en esto del .net y del POO pero no del VB6 el tema es, de que
manera puede facilitarme las cosas usando POO? por ejemplo tengo que hacer

un

form de ABM de clientes, creo la clase clientes y le doy sus atributos,

pero

despues como juego con el objeto? o sea no alcanzo a ver que utilidad

puede

llegar a tener usando POO de la manera en lo que lo hacia con VB6, se
entiende?

Muchas Gracias

Estimado amigo:

La programacion orientada a objeto no tiene una sola ventaja, es todo un
conjunto de ventajas.
Algunas de ellas son las que mencionaron en la respuesta a que permite
una mejor modularizacion del codigo y reutilizacion que es lo mas importante
para un desarrollo prolijo y para minimizar errores.

VB 6 si bien provee robustez, esta se queda corta a la hora de
interactuar con memoria, clases, polimorfirmo y derivacion y te explico
desde mi punto de vista porque:

1. En cuanto a memoria, al momento de hacer una herencia el objeto se
copiaba, generando el objeto nuevo y no teniendo una herencia real (a esto
me refiero con que deberia haber un puntero de referencia a los metodos, y
propiedades comunes y un sector dedicado de memoria para las nuevas
funcionalidades del objeto o clase). Esto con .NET se soluciono.

2. Las clases tienen hoy muchisimas formas mas de uso, por ejemplo aparecen
las clases friends(clases amigas) que son un hibrido entre publicas y
privadas y tenemos mucha mas amplitud a la hora de decidir que seguridad le
damos a cada metodo, propiedad o atributo de la clase.

3. El polimorfismo es real ya que no hay redundancia de datos en memoria ni
sincronizacion de clases, por lo explicado en el punto 1. En tu ejemplo,
puedo tener la clase clientes y de esta hacer un polimorfismo entre clientes
de sexo femenino en donde tendre propiedades como color de lapiz de labios
favorito y peluqueria preferida, mientras que por el otro lado tendre un
polimorfismo generado para los clientes de sexo masculino con el atributo
equipo de futbol preferido y marca de cerveza. Yo sigo trabajando con
clientes y al momento de establecer su sexo ya automaticamente trabajo
(gracias a la herencia y al polimorfismo) con una u otra instancia de la
clase con las propiedades que corresponda. En un ABM las propiedades que no
vayan se deshabiitan y desaparecen del form, por ejemplo, en los listados ni
aparecen, etc etc.-

4. En cuanto a la derivacion, derivar clases desde algo tan generico en .net
como lo es OBJECT permite adaptar la clase que se te ocurra agregandole y
quitandole lo que quieras (simpre que no se protected o readonly - logico) y
adaptar la clase a la funcionalidad que VOS quieras y no la que te da el
framework... por ejemplo: la clase sqlclient (para trabajar como cliente
sql)... si queres le agregas una propiedadd que almacene por darte un
ejemplo la cantidad de espacio libre en el server, esto lo definiste vos y
esta fuera del framework.. ellos te dan la clase base y a partir de ahi vos
pones tu imaginacion y haces lo que quieras...

El objeto lo que te proporciona es, me parece a mi, una consistencia, entre
lo que entra a tu aplicacion y la informacion que vos utilizas realmente
para trabajar. Ejemplo: ubicate en el objeto cliente al momento de dar un
alta. este objeto tiene la propiedad Apellido y Nombre que se encuentra en
el objeto (clase).. bien.. en el set y en el get ya validas todo lo que
parezca necesario para que ese dato (Apellido y Nombre) sea valido.. ademas,
definis una funcion que le saca la coma, otra que cuenta la cantidad de
letras y genera un numero de ID unico para el cliente (es un ejemplo), y
otra que verifica que no haya numeros. Luego de esto, y de ejecutadas todas
estas funciones en el GET recien estableces la propiedad Apellido y Nombre,
mas la propiedad ID... que te aseguraste??.. que aunque el usuario haya sido
un nabo que le metio un 9 en el medio del texto que estaba escribiendo, vos
se lo sacaste, le sacaste la coma, le generaste un numero de ID unico y en
sintesis, te aseguras que el dato esta listo para ser almacenado en la
base.. y que no vas a almacenar cualquier cosa ni que mañana ese cliente va
a ser inbuscable...

Y asi con cada objeto que manejes, las puertas de entrada de los mismo son
un filtro con el cual te aseguras que cada propieded o atributo que se
encuentra escrito es valido y paso los controles... eso te da la confianza
que necesitas para confiar en el dato puesto como propiedad, y de manera
analoga, cada propiedad que leas de un objeto va a tener la confianza
suficiente como para confiar en el.

Esta es mi humilde opinion y un punto de vista bastante sencillo, queria que
sepas algunos de los motivos por los cuales uno decide programar orientado a
objetos... hoy en dia, la reutilizacion de codigo es algo fundamental, el
codigo ya no se hace, la rueda ya esta inventada.. le podes poner logica a
los programas y agregarles funcionalidad.. y para hacer eso necesitas
heredar y heredar para trabajar en lo realmente importante que es la
funcionalidad agregada, a eso .NET lo hace transparente porque el codigo te
lo muestra, y no es una mera caja cerrada (COM) que no sabes como funciona
ni si esta bien hecho

Bueno, entiendan los MVP que es una humilde opinion, no quiero generar con
esto ningun tipo de discusion ni nada que se le parezca...

Un abrazo

Alvarez Arigos Roerto Miguel
Analista Superior de Sistemas

"SAM" escribió en el mensaje
news:

Hola muchachos, tengo una consultilla para hacerles:
Soy nuevo en esto del .net y del POO pero no del VB6 el tema es, de que
manera puede facilitarme las cosas usando POO? por ejemplo tengo que hacer

un

form de ABM de clientes, creo la clase clientes y le doy sus atributos,

pero

despues como juego con el objeto? o sea no alcanzo a ver que utilidad

puede

llegar a tener usando POO de la manera en lo que lo hacia con VB6, se
entiende?

Muchas Gracias