Implementación OOP

Todo lo que estás diciendo está bien, pero las clases
no te mandan a ti, tu las mandas a ellas y todo depende
de como las crees. Yo uso clases similares a las que tu comentas;
para el caso de las facturas tengo varias funciones, una para cargar la
cabecera, otra para cargar las lineas y otra para cargar la factura
completa. En el caso de los clientes se puede hacer una funcion
para que solo te recupere unos campos concretos (nombre, DNI, pej)

También puedes sobrecargar los constructores para que te creen las clases
con
los datos que tu requieras... hay muchas posibilidades

Pero en todo caso no te agobies y piensa en lo que quieres que te brinde
una clase antes de diseñarla y hazlo en consecuencia.

Saludos.

Saludos:

Te doy un par de consejos:

1. No cargues todos los campos de golpe si comunmente no se requieren todos,
solamente carga de forma preliminar los mas comunes, y los otros
implementalos a manera de propiedades donde la lectura se la hace bajo
demanda, es decir, si un campo no cargado es solicitado por el cliente,
carga los campos secundarios y activa un flag para que sepas que ese campo
ya fue traido de la base.

2. Cuando un objeto contiene otros objetos, por ejemplo, una objeto Ciudad
contiene un objeto Pais, no cargues el objeto Pais sino mas bien guarda
internamente el codigo del Pais. Si el cliente solicita o lee el objeto
Pais, solo entonces cargalo bajo demanda. Eso te ahorrara armar
construcciones de objetos cuyos datos vienen de una base, cuando realmente
la interfaz o el usuario de ese objeto no los va a utilizar.

Saludos
Pedro Luna
Gye, Ecu


"Miquel" escribió en el mensaje
news:
Mostrar la cita

Hola a todos,

Mi duda es referente al diseño de las clases.
Supongamos que tenemos una clase CLIENTE, que maneja todas sus propiedades
(código, nombre, cif...) además de controlar una colección de objetos
CONTACTOS de ese cliente.
Al crear un objeto CLIENTE, éste recupera todos sus datos de la bbdd,

además
Mostrar la cita

de crear tantos objetos CONTACTO como contactos tenga este cliente.
Esto funciona bien para un formulario que me muestre la información del
cliente, así como una grid que contenga a sus contactos.

Pero, si desde un formulario facturas (p. ej. ) necesito mostrar sólo
algunos de los datos de un cliente y para ello creo un objeto CLIENTE,

este
Mostrar la cita

se va a crear con todo. O sea, va a leer toda la información del cliente

así
Mostrar la cita

como toda la información de sus contactos. La qual cosa me parece absurda
por la pérdida de tiempo accediendo a unos datos que no voy a necesitar.

Es en casos como este que me pierdo a la hora de diseñar las clases.
Albaranes (cabecera y lineas), Facturas (Caberas y lineas)
Porqué diablos el objeto FACTURA me va a tener que cargar todas sus lineas
si en un momento dado sólo quiero obtener de él el importe total de la
factura????

Me gustaria si alguien puede aportar ideas de como diseña clases para
manejar objetos de tipos similares a los expuestos.

Muchas gracias,
Miquel

Hola Miguel:

En mi diseño, los Clientes no solo tiene contactos; tambien tienen un
expediente, que almacena todas las transacciones realizadas por ese cliente
desde el comienzo de su relacion con la empresa (o desde la fecha de la
última desincorporacion de datos ). A ese expediente se le pueden pedir
todos los documentos -especificando o no el tipo de operación o de
documento- o un documento especifico, o el primer documento o el documento
más reciente. Tiene tambien una estadistica de productos comprados.

Pero esa información, que en el diseño forma parte de la clase con una
relación de agregación (puede haber clientes sin expediente, ni contactos,
ni compra) se carga cuando resulta necesaria (aunque esto, por supuesto, no
se sabe fuera de la clase).

Si un cliente de Clientes requiere los contactos, estos se cargan de la BD
(normalmente utilizo colecciones para devolver los agregados de datos
subordinados a una clase: el prototipo de los metodos que devuelven
agregados es:

Public Function <NombreLogicoAgregado>(Optional Destino As IList = Nothing)
As Collection

la función va cargando las instancias del agregado (por ejemplo los
contactos) de la BD -sí, mis clases de dominio/aplicación implementan los
mecanismos de acceso a datos- y va agregandolas a una colección creada
localmente que sera el valor de retorno. Adicionalmente, si Destino no es
Nothing, agrega cada elemento a esta lista. IList es una interfaz utilizada
por una cantidad de controles de Windows Forms (cuadros de lista, combos y
creo que hasta los datagrid -que no hay manera de que aprenda a utilizar).

Si el componente cliente desea minimizar los accesos a la BD, almacena la
colección devuelta por la entidad en la primera llamada (p. ej. Dim
contactosCliente As Collection = Cliente.Contactos(), luego trabaja con
contactosCliente, evitando llamadas subsiguientes a Cliente.Contactos).

Salud!

Leonardo
[MVP Visual Basic (6)]
[Maicrosoft LVP - MOP Certified]
leonardo<arroba>mvps<punto>org



"Miquel" escribió en el mensaje
news:
Mostrar la cita

Hola a todos,

Mi duda es referente al diseño de las clases.
Supongamos que tenemos una clase CLIENTE, que maneja todas sus propiedades
(código, nombre, cif...) además de controlar una colección de objetos
CONTACTOS de ese cliente.
Al crear un objeto CLIENTE, éste recupera todos sus datos de la bbdd,

además
Mostrar la cita

de crear tantos objetos CONTACTO como contactos tenga este cliente.
Esto funciona bien para un formulario que me muestre la información del
cliente, así como una grid que contenga a sus contactos.

Pero, si desde un formulario facturas (p. ej. ) necesito mostrar sólo
algunos de los datos de un cliente y para ello creo un objeto CLIENTE,

este
Mostrar la cita

se va a crear con todo. O sea, va a leer toda la información del cliente

así
Mostrar la cita

como toda la información de sus contactos. La qual cosa me parece absurda
por la pérdida de tiempo accediendo a unos datos que no voy a necesitar.

Es en casos como este que me pierdo a la hora de diseñar las clases.
Albaranes (cabecera y lineas), Facturas (Caberas y lineas)
Porqué diablos el objeto FACTURA me va a tener que cargar todas sus lineas
si en un momento dado sólo quiero obtener de él el importe total de la
factura????

Me gustaria si alguien puede aportar ideas de como diseña clases para
manejar objetos de tipos similares a los expuestos.

Muchas gracias,
Miquel

Gracias a todos!
Mi error desde el principio fué pensar que las clases y los objetos harían
todo el trabajo por mi
La OOP ofrece muchas ventajas (cuando la acabas entendiendo). Pero lo que
está claro, es que en ese tipo de programación, el analisi debe ser mucho
más concienzudo.

Mis clases, empiezan a hacerme caso, y a hacer lo que yo les diga que hagan.

Miquel

"Miquel" escribió en el mensaje
news:
Mostrar la cita

Hola a todos,

Mi duda es referente al diseño de las clases.
Supongamos que tenemos una clase CLIENTE, que maneja todas sus propiedades
(código, nombre, cif...) además de controlar una colección de objetos
CONTACTOS de ese cliente.
Al crear un objeto CLIENTE, éste recupera todos sus datos de la bbdd,

además
Mostrar la cita

de crear tantos objetos CONTACTO como contactos tenga este cliente.
Esto funciona bien para un formulario que me muestre la información del
cliente, así como una grid que contenga a sus contactos.

Pero, si desde un formulario facturas (p. ej. ) necesito mostrar sólo
algunos de los datos de un cliente y para ello creo un objeto CLIENTE,

este
Mostrar la cita

se va a crear con todo. O sea, va a leer toda la información del cliente

así
Mostrar la cita

como toda la información de sus contactos. La qual cosa me parece absurda
por la pérdida de tiempo accediendo a unos datos que no voy a necesitar.

Es en casos como este que me pierdo a la hora de diseñar las clases.
Albaranes (cabecera y lineas), Facturas (Caberas y lineas)
Porqué diablos el objeto FACTURA me va a tener que cargar todas sus lineas
si en un momento dado sólo quiero obtener de él el importe total de la
factura????

Me gustaria si alguien puede aportar ideas de como diseña clases para
manejar objetos de tipos similares a los expuestos.

Muchas gracias,
Miquel