Consulta ejercicio QMP2

[LeandroFusetti]

Hola, tengo una duda con los requerimientos del ejercicio de QMP2 y con la resolucion que esta en el aula, pregunto por aca porque nose si llego a conectarme hoy.
La prenda solo va a poder ser instanciada desde la clase Borrador que seria una clase independiente de Prenda (segun la solucion planteada) pero nada me impide crear una instancia de Prenda sin usar Borrador, para eso Borrador tendria que ser una clase anidada de prenda y usar el constructor de Prenda (que tendria que ser privado) para instanciar la prenda?
O en los requerimientos no especifican que la prenda tiene que ser creada partiendo unicamente del borrador? de esta forma podria crear las prendas de ambas maneras, usando el borrador y haciendolo paso a paso o instanciando a la prenda directamente desde su constructor.
Tampoco me queda del todo claro como funciona el patron builder, si siempre tiene que ser una clase anidada (o metodo) de la clase que queremos instanciar (para que solo pueda ser instanciada a traves del builder) o puede ser una clase independiente de esta.

[flbulgarelli]

Hola @LeandroFusetti

La prenda solo va a poder ser instanciada desde la clase Borrador que seria una clase independiente de Prenda (segun la solucion planteada) pero nada me impide crear una instancia de Prenda sin usar Borrador...

Correcto. Y eso no es necesariamente malo: se trata de un contrato débil, es decir, un acuerdo explícito del equipo de desarrollo por el cual siempre utilizarán Borradores para instanciar prendas. Nada evitará que incumplan este acuerdo, y será la responsabilidad del equipo velar por que el mismo se observe (por ejemplo, a través de la realización de revisiones de código en pull requests). De hecho, incluso podría haber situaciones en que acuerden que es mejor ignorar este acuerdo, o plantear excepciones generales al mismo.

...para eso Borrador tendria que ser una clase anidada de prenda y usar el constructor de Prenda (que tendria que ser privado) para instanciar la prenda?

Sí, correcto. Allí estarías, en cambio, buscando crear un contrato fuerte, que impida la instanciación de la Prenda por fuera de un borrador. En otras palabras, acá el contrato no está siendo observado únicamente por el equipo, sino en primer lugar por las herramientas tecnológicas (en este caso, el compilador de Java).

Esto no es bueno ni malo por sí mismo, sino otra alternativa con sus propias ventajas y desventajas: garantiza que tu intención se cumpla siempre, a expensas de menor flexibilidad y una solución más engorrosa de codificar.

[flbulgarelli]

O en los requerimientos no especifican que la prenda tiene que ser creada partiendo unicamente del borrador? de esta forma podria crear las prendas de ambas maneras, usando el borrador y haciendolo paso a paso o instanciando a la prenda directamente desde su constructor.

Es importante notar que no todo requerimiento, expresado usualmente en términos humanos, de casos de uso e interacciones entre personas y el sistema (o entre otros sistemas y el nuestro), se mapea uno a uno a líneas de código. Quizás desde la aplicación siempre se creen las prendas siguiendo el proceso antes descripto, pero eso no necesariamente se traduce a que tus objetos tienen que crearse únicamente de esa forma. Definitivamente, que los objetos expresen fielmente a los requerimientos y que se comporten de forma consistente con los casos de uso es valioso, pero no siempre deseable y para nada exigible.

Por el contrario, en muchas ocasiones permitir situaciones que no se darían normalmente en el flujo primario de una aplicación puede ser beneficioso: por ejemplo, podría simplificar la escritura de tus tests, o permitir otros casos de uso (como integraciones con sistemas externos, herramientas de mantenimiento, etc) que no sigan fielmente el mismo flujo que una persona usuaria.

[flbulgarelli]

Tampoco me queda del todo claro como funciona el patron builder, si siempre tiene que ser una clase anidada (o metodo) de la clase que queremos instanciar (para que solo pueda ser instanciada a traves del builder) o puede ser una clase independiente de esta.

Ésto se desprende de mis comentarios anteriores: no, no tiene por que ser implementado de esa forma. No existe una única forma de "instanciar" a un patrón (es decir, de llevarlo a la práctica). Los patrones se caracterizan por los problemas que resuelven, la terminología que introducen, las estrategias de solución, componentes, responsabilidades y relaciones que presentan, las ventajas y desventajas que aportan. Las implementaciones que se describen funcionan a modo de referencia y variarían de situación a situación y de lenguaje a lenguaje.

En este caso particular, la esencia del patrón builder está en independizar la forma en que se configura a un objeto de su representación interna y posibilitar la construcción del mismo en varios pasos, potencialmente diferidos en el tiempo. Para ello se cosifica un objeto constructor (builder), que tendrá la responsabilidad de gestionar esas configuraciones y generar la representación concreta del mismo.

Luego, otras cuestiones como polimorfismo entre builders o subtipos, orden de las operaciones, acoplamiento entre el objeto constructor y el construído, etc, varían y las podrás encontrar en diferentes implementaciones y bibliografías.