Aprendiendo a pensar en Objetos (I)

En algunos artículos anteriores, e incluso en los vídeos, hago especial hincapié en la necesidad de estudiar los proyectos directamente como objetos en vez de hacerlo basándonos en la estructura de tablas a la que estamos acostumbrados.

Actualmente, cuando abordamos un nuevo proyecto, después de estudiarnos las especificaciones y tener un par de reuniones con el cliente, lo primero que hacemos es diseñar directamente la estructura de las tablas de la base de datos. No es que hacerlo está mal, es lo que estamos acostumbrados a hacer después de años de trabajo y era lo que aprendimos entonces. Pero pensándolo desde el punto de vista POO no nos vale ese planteamiento.

Después de escribir aquellos artículos recibí algún que otro correo en el que se me preguntaba que era eso de “pensar en objetos” y que como se hacía. El algunos de aquellos correos, los autores confesaban que no veían otra forma de hacer las cosas que no fuese diseñando las tablas primero.

Pues bien, hoy vamos a plantear un sencillo problema y a partir de ahí vamos a aprender a pensar en objetos olvidando el diseño de aplicaciones basado en tablas.

El problema

El cliente Cetanito,S.L, dedicado a la distribución de productos de consumo, nos ha  contratado para que le hagamos un sistema para poder efectuar facturas de sus productos a sus clientes. Cada cliente tiene acordada una forma de pago habitual que puede cambiar a la hora de hacer la factura por el motivo que sea (no nos importa) y debe especificarse en el documento de factura. Dependiendo de las formas de pago se generan una serie de vencimientos que deben aparecer en la factura. Los artículos tienen diferentes tipos de IVA que deben salir desglosados en la factura. Nos presenta el siguiente modelo de factura:

Factura

Factura

en cuanto a los artículos, nos indica que disponen de la siguiente información: código, descripción, precio y tipo de iva. Los datos que guarda de los clientes son el CIF/NIF, nombre, domicilio completo, teléfono, persona de contacto, teléfono de la persona de contacto y dirección de correo electrónico. Las formas de pago son simples y los vencimientos son regulares (generalmente de 30 en 30 días).

La solución

En este momento, y después de resolver las dudas que se nos hubiesen planteado, es cuando nos ponemos a trabajar y, siguiendo el modelo tradicional lo primero que se nos viene a la mente hacer es diseñar las tablas, y generalmente empezamos por las tablas maestras.

Pues bien, para pensar en objetos y empezar a solucionar el problema, en vez de basarnos en la estructura de las tablas maestras, lo primero que vamos a hacer es observar detenidamente la factura, que a fin y al cavo es el documento que debe generar nuestro sistema, e identificar las partes que la componen.

En primer lugar identificamos un objeto, la propia factura. Es un objeto físico y es susceptible de ser convertido en un objeto dentro de nuestro sistema. Vayamos poco a poco identificando las partes que componen la factura:

  • Los datos identificativos de la factura, número y fecha.
  • Los datos identificativos del cliente.
  • El detalle de la factura, con los productos que compra el cliente.
  • La forma de pago.
  • Los vencimientos generados por la forma de pago.
  • Los desgloses de los tipos de IVA aplicados.
  • El total de la factura.

Ahora veamos que elementos pueden ser objetos:

  • Los datos del cliente es un objeto Cliente.
  • Cada linea del detalle es un objeto Linea de Factura.
  • La forma de pago es un objeto Forma de Pago.
  • Cada vencimiento es un objeto Vencimiento.
  • Cada desglose de IVA es un objeto IVA.

Hay otros elementos de la factura que no son objetos y que son datos:

  • Dato Número.
  • Dato Fecha.
  • El total de la Factura es un dato que vendrá recalculado mediante un método.

Ahora, cuando hemos apartado la vista de la estructura de tablas y nos hemos centrado en objetos, podemos ver el problema desde otro punto de vista y tal como se muestra en la imagen:

Estudio del Objeto Factura

Estudio del Objeto Factura

Anuncios

2 comentarios

  1. Alfonso, como siempre genial. Y ahora como se plantearian las tablas?

    • Hola Pepe,

      Gracias por el comentario.

      Veremos el tema de las tablas más adelante. El objetivo es conseguir diseñar la aplicación sin pensar en tablas. Lo cierto es que como esté la información en las tablas es lo de menos.

      Un abrazo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: