Durante el último examen puse un ejercicio de aplicación de patrones de diseño que me permitió descubrir que es mas difícil entender los contextos de aplicación de lo que yo pensaba. En este examen el ejercicio fue el siguiente:
... se necesita un componente que permita acceder a documentos PDF en dos modalidades: una resumida que sirva como referencia al usuario para que pueda decidir cual documento abrir. Una vez que lo haya decidido, y ejecutado la acción de abrir documento, debe obtenerse el documento real. Proponga un esbozo de solución para el diseño del componente.
Esta claro (o al menos eso espero) que la respuesta es "necesitas un proxy" porque se trata de un recurso. Sin embargo recibí respuestas de toda índole, como por ejemplo:
- Composite, a lo cual digo NO porque es para modelar estructuras recursivas
- Template Method, a lo cual digo NO porque es para modelar algoritmos reutilizables
- Factory Method, a lo cual digo NO pues es para decidir que tipo de objeto crear
- Strategy, a lo cual digo NO pues es para decidir cual algoritmo utilizar dado el contexto
- Proxy, a lo que digo SI pues es para modelar representantes de objetos costosos
No hay que olvidar que todos estos patrones tienen una implementación similar puesto que aprovechan las ventajas de la herencia y el polimorfismo para dar la solución al problema; pero esto no quiere decir que sean lo mismo.
Cuando te enfrentes a un problema de diseño de software recuerda, tener presente mis comentarios anteriores para que puedas utilizar las herramientas correctas en los momentos correctos y así utilizar al máximo la solución que te proponen.
No hay comentarios:
Publicar un comentario
Si quieres puedes aportar a este post con tus comentarios, así podemos enriquecer juntos la temática. Gracias!