Taller de Programación Orientada a Objetos - Semana 7 - Reporte 6
COMPARACIÓN DE DIAGRAMAS
1. Diagrama diseñado por mi.
2. Diagrama autogenerado por mi código
Aunque en escencia son lo mismo, la verdad es que ambos difieren en varios aspectos.
Los mas importantes a resaltar son primeramente las variables. Podemos ver que en el diagrama que yo diseñe se ven las variables dentro de la cajita de las clases, pero en el diagrama autogenerado no aparecen. Esto es porque el nivel de acceso por default en el primer diagrama es "PUBLIC", mientras que en segundo diagrama mis variables estan declaradas como "PRIVATE", por eso aparecen ocultas.
Otra diferencia es la declaración de algunos métodos. Prinicipalmente los constructores de cada clase, que en el primer diagrama solo aparecen declarados y en el segundo aparecen incluso con los parámetros que éstos recibirán.
En ambos aparecen por medio de flechas con la punta en forma de rombo, las uniones de las clases que envían parámetros a otras, y el nombre de la variable arriba, debajo o a un lado de la flecha.
Para mi ambos tienen cosas que le faltan al otro. El primero muestra mas funciones, ya que es en el que estoy visualizando mi código con mas imaginación. Mientras que en el segundo me falta implementar mis ideas para que se complete correctamente.
COMPARACIÓN DEL CÓDIGO
El código fue muy diferente en ambos casos, para empezar, la autogeneración de código me produjo más clases que las que de verdad tengo y necesito, además de dividirme el proyecto en 2 partes: LogicalView (¿?) y toBill (paquete real):
Mayor cantidad de clases:
logicalview
toBill
Clases reales
Otra diferencia es que código autogenerado por el diagrama UML diseñado por mi no compilo muy bien, creo que se debío principalmente a la extraña forma en que se declaro el contructor de cada clase:
Algunos constructores autogenerados
Constructores correctos.
Otra diferencia que hay es que en lugar de tener un solo método para tomar los datos y posteriormente enviarlos al constructor, se autogeneraron varios métodos "GET" y "SET" (para tomar los datos y despues colocarlos en su atributo correspondiente).
Esto me dio un poco de desconfianza pero prefiero mi método personal el cual es más corto y funcional (en mi opinión)
Métodos SET y GET
Método getData()
Otro error visible en la autogeneración es que la clase Bill (factura) hereda los atributos de Paper (factura en papel) lo cual esta equivocado ya que es a la inversa:
Incorrecto (Autogenerado)
Correcto
Estos son los detallitos mas sobresalientes de ambos, lo demás son simples funciónes vacías las cuales ya estan completadas en mi código. Asi como espacios para los comentarios, etcétera.
SALUDOS!!!
Compadre solo me queda algo muy raro, tus precios los manejaras por strings? bueno dijiste que nunca cambiaria, sin embargo cuando una persona pida unos no se 5 chicles, vas a agregar los chicles 5 veces por precio unitario? o bien lo que yo te puedo recomendar es cambiarlo a un float y ya podrias simplemente hacer una multipliacion variables flotantes, ya que hasta donde yo tengo conocido no puedes sumar strings de numeros. Solo una recomendacion
ResponderEliminarGracias Hector, de echo ayer le meti más mano a mi código y ya cambie esos detalles. Los maneje como strings de forma temporal, pero ahora las cantidades ya son enteros INT y los precios ya son DOUBLE, puesto que ya voy a comenzar a implementar métodos para calcular totales, descuentos, etcétera.
ResponderEliminarGracias por la observación
Héctor otra vez ganándose un punto extra. Lo de dos constructores vacios es porque la herramienta supone que vas a poner uno con parámetros y uno sin parámetros. Lo único que faltó aquí es lo de generación de diagramas de secuencia. Es muy completo lo de autogeneración. Te pongo 8 para el taller.
ResponderEliminarSe me olvidó mencionar que también es +1 extra para JC por la respuesta.
ResponderEliminar