¡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 ...

  dds/01-lecture/quemepongo/src/main/java/quemepongo/Prenda.java

  Lines 58 to 62 in a6514ee

  	public Prenda(Tipo tipoPrenda, Color principal, Material matnr) {
  	tipo = tipoPrenda;
  	color1 = principal;
  	material = matnr;
  	}

  ... debería delegar en el segundo ...

  dds/01-lecture/quemepongo/src/main/java/quemepongo/Prenda.java

  Lines 64 to 78 in a6514ee

  	/**
  	* 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 algunos comentarios sobre la entrega QMP4.

1. Me perdí un poco con el diagrama de clases, el hecho de que esté en partes dificulta su lectura (cómo se relacionan entre si esas clases? están separadas del resto del sistema?) Te sugiero que por iteración hagas solo 1 diagrama con las clases relevantes a esa iteración (no sería muy grande porque lo limitamos por iteración).
2. Muy bueno que venis haciendo tests para las entregas!
   

   dds/01-lecture/quemepongo/src/test/java/quemepongo/service/ClimaTest.java

   Lines 16 to 20 in 76f3735

   	public void climaBaires() {
   	Assertions.assertDoesNotThrow(() -> {
   	new AccuWeatherAPI().getWeatherForBuenosAires();
   	});
   	}

   
   En este caso, el assert está teniendo poco sentido porque en realidad en todos los casos (excepto los de error) queremos que no arroje excepción un método. No estamos verificando que funcione bien. Una opción es testear lo que devuelve ese método contra lo que esperás que devuelva, de esa forma si tenemos algún error en la lógica nos vamos a enterar.
3. AccuWeatherAPI es parte de un SDK cuyo código no podemos modificar, por lo cual no podemos hacer que implemente ClimaService. Como vimos en clase, sí podemos envolverlo y adaptarlo para que devuelva lo que le sirva al dominio.
4. Ojo con el uso del nombre service. Como vimos en clase, un service puede ser literalmente cualquier cosa. Veo que estás usando la palabra service como nombres de packages en Java. Qué clases queremos agrupar bajo este concepto? Es muy vago y amplio y termina siendo una bolsa de gatos. Una opción es hacer packages que representen funcionalides de dominio.
5. No hagas código que no se vaya a utilizar o por las dudas. Por ejemplo, todo lo que está dentro de Clima... a qué funcionalidad responde del enunciado? Esto generó un sobrediseño, una complejidad accidental que no esperábamos para este ejercicio.
6. Qué funcionalidad cumple la clase Pronostico? No tiene ningún comportamiento. Para evitar esto, podemos tener como atributo ClimaService donde lo vayamos a utilizar.
7. La idea de fabricar las prendas excede al enunciado, y está complejizando mucho el diseño. Se podría hacer mucho más simple si las prendas ya existieran y se eligiera sobre esas. Además, no encontré donde efectivamente se recomienda un atuendo dependiendo del clima.

Saludos!

¡Hola Tomás!

Te dejo algunos comentarios relacionados al ejercicio de Macowins:

1. Veo que incluiste en tu README algunos ejemplos de consultar a nivel datos y te recuerdo que en esta primera mitad no nos interesa pensar en tablas ni consultar SQL (así como tampoco incluir atributos cuyo único propósito esté relacionado a eso como por ejemplo el atributo nroDeVenta) sino que nos vamos a enfocar exclusivamente en el modelado del dominio a nivel objetos
2. En general veo que optaste por guardar datos y modificarlos a lo largo del tiempo en lugar de calcularlos dinámicamente, lo cual suele agregar complejidad innecesaria en la resolución del problema y, de estar mal manejado, podría llevar a inconsistencias. Preferimos realizar los cálculos de forma dinámica cuando sea posible y reducir los métodos con efecto (por lo que tampoco sería necesario tener cosas como modificar para el precio, liquidar para una prenda o vender para una venta.
3. Algunas ideas parecen estar sobrediseñadas (por ejemplo el ModificadorDePrecio que podría ser parte del mismo estado de la prenda) y hay otras que no tienen tanta cohesión y podrían ser delegadas a otros objetos (como la lógica de los descuentos que en realidad no aplican a todas las prendas si no solo a algunas de ellas o el método de pago que no está reificado sino que también es responsabilidad de la prenda, lo cual hace que el código sea más difícil de entender, testear y menos flexible)