Nun, der Fall dass man etwas löscht und dabei die Selektion dieses Objektes aufgehoben werden muss, war eben so ein Beispiel. Die durchgeführte Aktion ist "Delete". Also erstellt man ein DeleteCommand, und das ruft
model.delete(node);
auf. IN dieser Methode wird aber z.B. auch die Selektion aufgehoben. Wenn man das Delete rückgänig macht, z.B. durch
model.add(node);
dann ist der Knoten danach nicht ausgewählt. Das DeleteCommand müßte also auch über die Selektion bescheid wissen. Wäre das dann
[code=Java]
void execute() {
if (model.isSelected(node)) {
// Wird bei model.remove intern automatisch gemacht,
// aber damit man es rückgängig machen kann...:
subCommand = createSubCommandToUnselect(node);
}
model.remove(node);
}
void undo() {
model.remove(node);
if (sumCommand != null) subCommand.undo();
}
[/code]
? Aber üblicherweise ist "model" nur ein Interface, und man weiß im Zweifelsfall nicht, was bei einem "remove(node)" alles NOCH passiert....
Vielleicht geht es nur um die allgemeine (SEHR offensichtliche, aber doch schwierig zu beantwortende) Frage, wie man den Systemzustand "kapselt", und sicherstellt, dass ALLE (auch indirekten) Folgen einer Aktion rückgängig gemacht werden. Ab einer bestimmten Komplexität kommt sowas wie Memento IMHO auch nicht mehr in Frage. Man bewegt sich durch die Methodenaufrufe u.U. durch einen sehr komplexen Zustandsraum.
@bygones: Ich kann mir nicht vorstellen, dass dieses Kapseln und Konservieren des Systemzustandes möglich ist, NUR indem man auf Events hört. Spacerat hat da ja ein Beispiel gepostet.
@Spacerat Vielleicht sehe ich (mal wieder) ein Problem, wo keines ist 
Ich will das ganze aber nicht zuuu sehr problematisieren, man findet da sicher eine Lösung, und vermutlich muss ich es nur ein, zwei mal "falsch" implementieren, um zu sehen, wie es richtig gegangen wäre.
Ich hatte ja auch nur nach Best Practices gefragt, bzw. nach Beispielen, die über solche trivialen wie deins ( :bae: ) hinausgehen. Dass man ein "list.add(x)" oder "image.setRGB(...)" leicht rückgängig machen kann, ist klar. Aber stell dir vor, du würdest jetzt in die BufferedImage-Doku schauen, und dort eine Methode sehen wie
int getLastSetRGB(...)
die die zuletzt mit setRGB gesetzte Farbe zurückliefert: Dann wäre dein Undo schon "kaputt" bzw. unzureichend, und im schlimmsten Fall könnte so eine Aktion dann gar nicht rückgängig gemacht werden. Aber das liegt dann wohl in der Verantwortung desjenigen, der das Modell entwirft. Die einzig sinnvolle "übergeordnete" Gegenmaßnahme, die mir demnach jetzt einfallen würde, wäre, das gesamte Modell explizit auf undo/redo auszurichten, indem man ganz gezielt die Methoden entsprechend "paarweise" anbietet, aber das könnte im Einzelfall dann doch schwierig werden...
