Aproximacion a la POO

"lucho" escribió en el mensaje
news:

Si quiero usar la Prog. Orientada a Objetos en .NET y en prog. en 3 caps,
¿está bien hacer lo siguiente?:

1) Tengo un form. con 3 text boxs: txtIdentif ,txtNombre y txtDireccion.
2) Dentro de la clase del form defino 2 variables privadas strNombre y
strDireccion y 2 propiedades públicas Nombre() y Direccion() que me
devuelven
o setean las variables privadas
3) Defino otra clase CapadeDatos, en la cual defino nuevamente 2 variables
privadas strNombreW y strDireccionW y 2 propiedades públicas NombreW() y
DireccionW() que me devuelven o setean las variables privadas respectivas
desde o hacia la BD.
4)Proceso:
a)Digito un nro. de identif. en la caja de texto txtIdentif
b)En el procedimiento Click del botón OK, llamo a un sub "Ret" que
usando
como argumento txtIdentif.text , devuelve los valores nombre y direccion a
sus cajas de texto. Para hacerlo, dentro del cuerpo del sub "Ret"
instancio
la clase CapadeDatos y llamo a otro sub contenido en esta, "RetD", el cual
accede a la BD.
c) Los datos (si existen) de la BD, nombre y direccion correspondientes a
la
identif., son cargados en las variables privadas de la clase CapadeDatos
strNombreW y strDireccionW .
d) Las propiedades NombreW y DireccionW de la instancia de CapadeDatos,
cargan los valores respectivos, en las variables privadas strNombre y
strDireccion de la clase form (clase llamadora).
f) Finalmente, las propiedades privadas Nombre y Direccion de la clase
form, devuelven los valores en las cajas de texto txtNombre y
txtDireccion.
¿Esta bien hacer todo esto, o es solo un engorro? ¿Hay formas más fáciles
respetando la POO?
cordialmente

Hola Lucho:

La POO es simplemente una manera de pensar formalizada en un conjunto de
conceptos y soportada por algunas herramientas de desarrollo. No hay nada en
ella que deba ser respetado.

La "manera de pensar" se caracteriza fundamentalmente porque se basa en los
conceptos del universo de aplicación (clientes, pacientes, vehiculos,
cosechas) haciendo abstracción de los recursos y de las herramientas.

Es decir: un formulario siempre es un formulario, pero tambien es el
componente de interfaz con el usuario de una entidad.

Supongamos que esa entidad es un cliente.

Un cliente es tambien una entidad persistente. Eso significa que deben
poseer algun metodo para "guardar el estado entre dos ejecuciones de la
aplicacion". Ese método debe poder ser llamado desde arriba [algo asi como
unCliente.Actualizar()]. Por debajo, ese método "habla" con la "capa de
datos".

La "capa de datos" tiene la responsabilidad principal de ofrecer una
interfaz que oculta los detalles específicos de la implementación. ADO.NET
*es* la capa de datos: no es necesario que nosotros incluyamos una capa de
datos en nuestra aplicación. Lo hice en una aplicacion grande de VB6, y
detesto los resultados.

Es decir, dentro de la clase Cliente puedes escribir el código necesario
para grabar en la base de datos y para recuperar los valores contenidos en
ella.

Si tienes un formulario para la Alta/Baja/Modificacion y Consulta de
clientes, lo mas sensato es que tengas una variable de tipo Cliente, a la
cual le pases el código que el usuario acaba de escribir y se ocupe de traer
los datos. La responsabilidad de cargar los controles con los valores
correspondientes debe ser exclusivamente de la forma. Es decir, el núcleo
del objeto Cliente no debe tener idea de que existen formularios.

A efectos de la selección, búsqueda y creación de nuevos clientes,
normalmente es conveniente asignar parte de la responsbilidad a un control
de usuario (se supone que vas a leer codigos de cliente en una variedad de
contextos, y es bueno que puedas disponer de un componente reutilizable que
encapsule toda esa funcionalidad). Ese componente visual puede servir como
una representación del cliente a nivel del formulario.

Cada cosa que puedas nombrar en tu modelo es una clase: entidades,
documentos, operaciones (definidas como un par <Controlador,
PaqueteDeArgumentos>), consultas SQL, reportes

La eficiencia en el desarrollo de metodos OO viene despues de mucho tiempo
de estudio y experimentación. Es posible establecer algunas "recetas". El
conjunto de recetas es lo que se llama un método. Los metodos mas usados -al
menos los que tienen más prestigio- son el llamado "RUP" (Rational Unified
Process), para equipos de trabajo corporativos, y Agile o Extreme
Programming para desarrolladores individuales o equipos pequeños.

Te recomiendo que antes de escribir una sola línea de código, le des una
mirada a los siguientes libros:
"Analisis y Diseño Orientado a Objetos" de Grady Booch
"UML y Patrones" de Craig Larman
"UML gota a gota" de Martin Fowler
"Agile Software Development" de Robert Martin
"El proceso unificado de Desarrollo", de Grady Booch, James Rumbaugh e
Ivar Jacobson.
"Design Patterns" de Gamma, Helm, Johnson y Vlissides.
más o menos en ese orden.

El último es realmente difícil, pero vale la pena intentarlo una y otra vez.
El primero es una excelente introducción a los conceptos. El segundo es una
introducción a UML y al uso de patrones de diseño. El de Fowler es una
presentación muy racional y muy practica de UML, la notación gráfica
estándar del A&DOO. Los dos siguientes son descripciones del método de
desarrollo, que te permitirán un poco ver los conceptos en acción.

Con menos que eso, sólo vas a tirar palos de ciego.


Salud!