Correciones/comentarios: - mvn clean test no compila. Este es un error grave, no estan seteando la versión del compilador en maven. Ver http://sites.google.com/site/tacsalumnos/Home/apuntes/maven---generar-un-artefacto-bsico-desde-cero - Las configuraciones del eclipse no deberían estar en el repositorio. Ya que cualquier de ustedes podria usar otro ide. justamente maven nos permite independizarnos de esto. Al subir la config del eclipse al svn no se dieron cuenta del primer error que les marqué. - Como recomendación no usen caracteres del tipo ñ en los nombres de variables. Si bien java lo soporta van a tener considerables problemas con el encoding a la hora de compilar su codigo en distintas plataformas. Esto se soluciona agregando al pom.xml: <properties> <project.build.sourceEncoding> Cp1252</project.build.sourceEncoding> </properties> Sin embargo sean concientes de que esto restringe la portabilidad de su código. - Esto no es muy prolijo: (Revizar todas las clases en base a esta correción) .... private String codigo = ""; private String descripcion = ""; private EstadoPieza estado = EstadoPieza.DISPONIBLE; private Categoria categoria = Categoria.DEFAULT; private Auto autoOrigen; private double precio; /** * Contruye una pieza con {@code codigo = "", descripcion = "", estado = * EstadoPieza.DISPONIBLE, categoria = Categoria.DEFAULT, autoOrigen = null, * precio = 0} */ public Pieza() { super(); } Debería ser: private String codigo; private String descripcion; private EstadoPieza estado; private Categoria categoria; private Auto autoOrigen; private double precio; /** * Contruye una pieza con {@code codigo = "", descripcion = "", estado = * EstadoPieza.DISPONIBLE, categoria = Categoria.DEFAULT, autoOrigen = null, * precio = 0} */ public Pieza() { codigo = "": descripcion = ""; // etc... } - Mientras que en los estados podemos suponer un numero finito por regla de negocio, las categorías son algo más cambiante. Esto no debería ser una enum. - Tengan mucho cuidado con el uso de RuntimeException. Acá se plantean distintas opciones, lo importante es que sepan defender porque tomaron la decisión que tomaron. Opción 1: No deberían ser usadas para control de negocio sino para errores irrecuperables del sistema y usar checked para errores de negocio con una buena jerarquía. Opción 2: Usando las Runtime para temas de negocio evito ensuciar el codigo con las firmas y try/catch. Para los errores irrecuperables del sistema, tengo los Error. Para los errores irrecuperables del negocio, tengo log, cartel al usuario. Puede ser mas correcto usar las checked exception cuando trabajo sobre una API o una interfaz a otro sistema o componente. Sin embargo en este caso deberían ser manejadas en algún lugar y no llegar a consola o UI sin ningún tipo de tratamiento. Elijan una de estas opciones, modifiquen su código en base a la elección y justifiquen su elección en la entrega presencial. Tareas del segundo sprint: - En cuanto al segundo backlog, cual es el formato del log transaccional al que se hace referencia?
|
2010C1 > Correcciones (TP de desarrollo) >