Respuesta al Reto 5 Clases Abstractas
Las clases abstractas son clases que sirven para definir las propiedades y el comportamiento de sus clases derivadas. Establecen el límite conceptual del objeto identificado en el diseño de la solución al problema a resolver. Es conocida como la super clase y no se puede instanciar un objeto de ella. La idea es heredar clases instanciables a partir de esta clase. Nos puede servir para especificar un comportamiento mínimo de una clase, para que en un grupo de programadores los que requieran este tipo deriven sus clases a partir de ella. Las clases abstractas existen en los lenguajes mas populares como C#, Java y PHP.
Es complicado diseñar los elementos que van a componer la solución al problema que se pretende resolver con un programa si no se tiene un amplio conocimiento del dominio de ese problema. Asi que proponer en base a solo al nombre de una clase, no es posible. La idea de este reto es motivar a los que deseen resolverlo a imaginarse y a pensar que es lo que representa el concepto de un producto y de un cliente en un sistema de punto de venta.
En el caso del producto podemos pensar en una lata de frijoles en una tienda de abarrotes, un par de zapatos en una zapatería o un juego de herramientas en una ferretería. Aqui lo importante es determinar por medio de una clase los límites de esa abstracción. En lo que a mi experiencia se refiere, pensar en un artículo o un producto, me hace pensar en todas las posibilidades que cada uno de mis clientes me ha planteado: que tenga descripción, que tenga una clave fácil de recordar por los empleados, que tenga un código de barras, que se sepa a cuanto se compro, es decir su costo, a cuánto se va a vender, su porcentaje de iva. Características asociadas con el inventario como la cantidad que se tiene en la tienda (existencias), el límite de esas existencias para pedir mas (cantidad en stock o punto de reorden), que tipo de costeo se va a manejar (costo promedio, primeras entradas, primeras salidas, identificado), cuál va a ser su ubicación en la tienda, su unidad de medida. Otras quizás mas específicas como a que categoría pertenece, si el producto se vende suelto o por paquete o si tiene una gama de colores. En realidad las posibilidades son enormes.
Lo que yo propongo es agrupar los atributos más básicos en la clase abstracta y después en las clases concretas ir generando clases mas complejas, que vayan incluyendo las características adicionales mas específicas.
Mi propuesta se muestra en la siguiente figura:
Observen el esterotipo de la clase encerrada entre <<>>. Solo se tiene una clase abstracta y las demás son clases concretas (clases que si se pueden instanciar).
A ver que les parece, espero sus opiniones y críticas. La idea de poner las clases concretas es para mostrarles donde pongo las demás propiedades que no están definidas en la clase abstracta. En mi diseño intenté poner los atributos generales mínimos que definen a la clase productos y posteriormente fuí agregando características mas complejas, como el caso de la unidad de medida, que yo lo planteo como una clase y la categoría a la que pertenece el producto.
Con respecto a la clase abstracta de clientes, en un sistema de punto de venta, el cliente se define como la persona que compra en la tienda. Esta persona puede solicitar una factura, por lo que es importante tener sus datos fiscales, asi como los datos de su dirección. Ademas, un cliente puede ser una empresa, por lo que la persona que llega a comprar puede que sea la persona que hace el contacto.
Es por ello que mi propuesta de clase abstracta y sus clases concretas, es la siguiente:
Nuevamente espero sus comentarios.
Conclusión
En el diseño de clases es necesario contar con una vista jerárquica de interacción de clases que permita ir definiendo objetos de lo general a lo particular. Esto facilita la creación de nuevas clases y el reuso de las existentes en una forma ordenada. Anteriormente creaba clases con todos los atributos y derivar de ellas era un problema, pues existían atributos que no utilizaba. Las clases abstractas definen el inicio de la jerarquía de un grupo de objetos, que puede irse incrementando, dependiendo de las necesidades del sistema. Es pensar en una superclase que sirva como base para que los programadores de la misma empresa deriven sus clases de ella y no tengan que conocer el dominio completo del problema, pues en ella esta contenida la funcionalidad básica.
