Patrón de comando para deshacer / rehacer en la aplicación de pintura

Me gustaría implementar deshacer / rehacer en una pequeñaaplicación de pintura. Parece elPatrón de comando se adapta muy bien al uso, pero no estoy seguro de cómo implementarlo mejor.

Como entiendo el patrón, es necesario incluir en cada comando:

Los detalles de la operación de pintura para fines de rehacer (por ejemplo, Línea -> puntos de inicio y fin, línea de forma libre ->GeneralPath)El estado del componente antes del cambio para deshacer. En este caso, será una imagen de instantánea pequeña del área afectada por el comando.

Mi entendimiento, basado en eso, es que cada comando debe ser 'atómico' o autocontenido, con toda la información necesaria para deshacer / rehacer esa operación.

Desafortunadamente, eso requeriría almacenar más información de la que anticipé. Para una línea también debemos tener en cuenta cosas como laColor, Stroke yRenderingHints solía dibujarlo inicialmente. Esto convierte mis 'pequeños y sencillos comandos' en algo ... más voluminoso en la memoria, y con más código de placa de caldera para producir (cada uno será un bean serializable1).

Por razones de conservación de la memoria (en su mayoría) quería "hacer trampa" en la especificación de los comandos. Tal vez haga una copia de seguridad de toda el área de dibujo cada actualización número 100, pero de lo contrario no almacene ninguna parte de la imagen modificada, y simplemente vuelva a generar los últimos (hasta) 100 comandos para cada nueva operación de pintura. Pero eso parece problemático para asegurar que el estado de laGraphics el objeto está justo antes de pintar cada parte; esta parte puede requerir una línea, pero laRenderingHints Se cambiaron hace 4 comandos, elColor Se cambió hace 98 comandos, mientras que elStroke ha permanecido igual para los últimos 227 comandos.

La búsqueda de un comando más eficiente en memoria parece arrojar el patrón de la ventana en términos de ser "atómico". Eso, a su vez, conlleva dificultades para determinar el comando más antiguo que podría afectar la representación.

Debería:

¿Buscas un nuevo patrón?¿Intentar implementar mis necesidades peculiares ajustando el patrón?¿Deseche todo esto en la papelera como optimización prematura y codifíquelo de la manera más simple (y que consume más memoria) que se adhiere al patrón de comando como se define?Actualizar"Cada uno será un bean serializable" En 2do pensamientos, no. Hice controles de cúpula para encontrar que unGraphics2D (que encapsula perfectamente muchos parámetros utilizados al dibujar) no es serializable. Además, unBasicStroke es Serializable, pero el grosor del trazo no se almacena. Podría crear versiones serializables de muchos de los atributos, pero parece ser un código mucho más, así que voy a abandonar esa especificación. también. Sólo intentaré almacenar una referencia a unBufferedImage en tiempo de ejecución.