¡Buenas!
Te dejo nuestros comentarios:
- ¡Muy bien comunicada la solución!
- Si el
tipo ya sabe su categoría, ¿para qué permitir crear prendas con categorías? Esto no sólamente agrega complejidad innecesaria, sino que abre la puerta a inconsistencias que luego tendrás que validar a mano, cuando estructuralmente tus clases ya prevenían estas situaciones. Te propogo quitar la relación Prenda ➡️ Categoria
- 🆙 Viendo el código entiendo que es un problema de diagrama y no realmente de cómo pensaste la solución.
- Dado que el término tipo es muy genérico, renombraría el enum
Tipo a TipoPrenda
- El primer constructor ...
|
public Prenda(Tipo tipoPrenda, Color principal, Material matnr) { |
|
tipo = tipoPrenda; |
|
color1 = principal; |
|
material = matnr; |
|
} |
... debería delegar en el segundo ...
|
/** |
|
* Instancia una prenda con dos colores |
|
* |
|
* @param tipoPrenda - el tipo de la prendas |
|
* @param principal - el color principal |
|
* @param secundario - el color secundario |
|
* @param matnr - el material con el que está hecha |
|
* @author Tomás Sánchez |
|
* @since 1.0 |
|
*/ |
|
public Prenda(Tipo tipoPrenda, Color principal, Color secundario, Material matnr) { |
|
tipo = tipoPrenda; |
|
color1 = principal; |
|
color2 = secundario; |
|
material = matnr; |
... para evitar repetición de lógica.
- Aún así, cuidado con los llamados "constructores telescópicos" en los que tenés muchos constructores en los que se establece una cadena de delegación larga sólamente a fin de simular parámetros opcionales: esta estrategia es poco flexible y con apenas un par más de dependencias se volverá difícil de mantener
- 👀 ¡Ojo! Que marques a un atributo como final no evita que le pasen
null al pasarlo por parámetro en el constructor, sino sólo que no se pueda modificar una vez asignado. Por lo tanto tu constructor es un buen lugar para aplicar el principio de fail fast e introducir validaciones de presencia (por ejemplo usando Objects.notNull) dado que es algo en que se hace cierto hincapié en el enunciado al decir que las prendas deben ser válidas y que tenés un color obligatorio y otro secundario opcional.
¡Saludos!
¡Buenas!
Te dejo nuestros comentarios:
tipoya sabe su categoría, ¿para qué permitir crear prendas con categorías? Esto no sólamente agrega complejidad innecesaria, sino que abre la puerta a inconsistencias que luego tendrás que validar a mano, cuando estructuralmente tus clases ya prevenían estas situaciones. Te propogo quitar la relaciónPrenda➡️CategoriaTipoaTipoPrendadds/01-lecture/quemepongo/src/main/java/quemepongo/Prenda.java
Lines 58 to 62 in a6514ee
dds/01-lecture/quemepongo/src/main/java/quemepongo/Prenda.java
Lines 64 to 78 in a6514ee
nullal pasarlo por parámetro en el constructor, sino sólo que no se pueda modificar una vez asignado. Por lo tanto tu constructor es un buen lugar para aplicar el principio de fail fast e introducir validaciones de presencia (por ejemplo usando Objects.notNull) dado que es algo en que se hace cierto hincapié en el enunciado al decir que las prendas deben ser válidas y que tenés un color obligatorio y otro secundario opcional.¡Saludos!