Develop Reference

Behavior Tree: How/When to return "running" state on leaf nodes?

I've implemented a simple Behavior Tree algorithm which I intend to use inside a Unity project. It's mostly working as I expected, except I'm having trouble making proper use of it, which might be caused by some misunderstanding of mine. My problem is as follows:
If a leaf node takes a long time to finish, for instance, an action that makes a game unit follow a specific path, that means the leaf node is currently at the "running" state. However, if I return the state, I can no longer run the rest of the function, which means I can't reach my destination.
So my question is: what is the proper way to tell my tree that a leaf node is running?
Here's what I got on my ActionNode class:
public class ActionNode : BTNode
{
public delegate NodeStates ActionNodeDelegate();
protected ActionNodeDelegate nodeAction;
public ActionNode(ActionNodeDelegate action)
{
nodeAction = action;
}
public override NodeStates Evaluate()
{
switch (nodeAction())
{
case NodeStates.FAILURE:
currentNodeState = NodeStates.FAILURE;
return currentNodeState;
case NodeStates.SUCESS:
currentNodeState = NodeStates.SUCESS;
return currentNodeState;
case NodeStates.RUNNING:
currentNodeState = NodeStates.RUNNING;
return currentNodeState;
default:
currentNodeState = NodeStates.FAILURE;
return currentNodeState;
}
}
}
If you need to check the other classes, it's all based on this article. Linking it for the sake of keeping the thread cleaner.
As for an action example, consider this:
private NodeStates FollowPath() {
bool targetReached;
if (targetReachable)
targetReached = WalkToTarget();
if (targetReached)
return NodeStates.SUCESS;
else
return NodeStates.FAILURE;
}
What I'm wondering is, if WalkToTarget takes a long time, how do I return a "running" state?
I've read many different articles on the subject, but I can't seem to grasp the exact concept behind these states. I understand how I can, for instance, tell that a Sequence or Selector node is running.
The only idea that crossed my mind is that I'd store the remaining path inside a variable at my enemy class and call the method every game update tick, but I feel like that's just poor coding.
Are leaf nodes supposed to return "running" at any given moment? If so, in which cases would that happen? Any examples would be appreciated!

Okay, I figured out what I was doing wrong. I was assuming that my tree was responsible for executing the action code, when it is actually supposed to only evaluate the state of every node. In this case, my above example would change to something like this:
private NodeStates ShouldFollowPath() {
if (targetReachable && this.position != target.position)
return NodeStates.RUNNING;
else if (this.position == target.position)
return NodeStates.SUCESS;
else
return NodeStates.FAILURE;
}
And then I'd check the state of the above Node after evaluating the tree and execute my FollowPath code:
private ActionNode FollowPathNode = new ActioNode(ShouldFollowPath);
private void Update()
{
FollowPathNode.evaluate();
if (FollowPathNode.nodeState == NodeStates.RUNNING)
FollowPath();
}
In summary, I misunderstood the usage of the behavior tree. The above example solves my problems.

WPF validation of input (on-the-fly) and unit test. Best practice for design

I want to add a new form to an existing solution. The solution already has a Validator class, so I want to expand this class.
The Form I want to create contains a Textbox (for the input) and a Button. When the input is the correct format the submit button is enabled. The input must adhere to a certain regular expression: "^[A-Za-z]{2}[0-9]{5}$". I'm checking the input (on-the-fly) in the Form class like this:
private void inputTbx_TextChanged(object sender, TextChangedEventArgs e)
{
SubmitButton.IsEnabled = Validator.IsInputValid(inputTbx.Text, RegexExpression);
}
I've put the regular expression as a variable in the Form class. I put it here because it is relevant to the textbox of this form only.
private const string RegexExpression = "^[A-Za-z]{2}[0-9]{5}$";
Here's the validation code:
public static bool IsInputValid(string inputToBeChecked, string regexExpression)
{
if (inputToBeChecked == null || regexExpression == null)
{
return false;
}
var regex = new Regex(regexExpression, RegexOptions.None);
return regex.IsMatch(inputToBeChecked);
}
So far so good. It seems to work fine. But I want to unit test it like so:
[TestCase("aZ13579")]
public void ValidateInputOkTest(string input)
{
Assert.IsTrue(Validator.IsInputValid(input, RegexExpression));
}
But to do it like this I have to have a string in my ValidatorTest class similar to the Regular-expression used in the Form class. This doesn't seem like the right way to do it. What I really want to do is get the Regex expression from the form class, so I am sure it's the correct Regex-expression that I'm using. Otherwise the Regex-expressions could easily get out of sync.
Here are the questions:
What is best practice here?
How do I get to this expression? I've tried doing it using Reflection, but I get a Threadstat error because it's a GUI component. Should I move the Regular-expression? If so where to?
I'm thinking there must be a smart way to do this. A smart design perhaps. Suggestions and comments are welcome.

You're probably going to want to back up a step and start to research the 'MVVM' design pattern. When you hear people talk about putting no code in the code behind, testing like this is one of the big benefits (among many others).
MVVM is too big a topic to handle in a simple answer like this. I'd search around on the web, and I'm sure other people have some good tutorials.
Just to be clear, it can be a big learning curve, but it's totally worth it. MVVM is what makes WPF much much (MUCH) better than WinForms, rather than merely different.
Just to address your question a little more specifically, you won't be testing a GUI object like a Window or UserControl. You'll be testing a view model which is just a regular class.
Here's a simplified version of what you might see
public class MyScreenViewModel : INotifyPropertyChanged
{
private const string RegexExpression = "^[A-Za-z]{2}[0-9]{5}$";
public bool UserInputIsValid { get { stuff; } set { stuff; }}
public string UserInput { get { stuff; } set { stuff; ValidateUserInput();} }
private void ValidateUserInput()
{
if (UserInput == null)
{
return false;
}
var regex = new Regex(RegexExpression, RegexOptions.None);
UserInputIsValid = regex.IsMatch(UserInput);
}
}
A view model in MVVM is the real logic of your screen. It will expose simple properties that the view can bind to for display/input, but the view isn't necessary for testing the logic.
Then your test looks something like:
[TestCase("aZ13579")]
public void ValidateInputOkTest()
{
var vm = new MyScreenViewModel();
vm.UserInput = "SomeValidText";
Assert.IsTrue(vm.UserInputIsValid);
}
[TestCase("aZ13580")]
public void ValidateInputNotOkTest()
{
var vm = new MyScreenViewModel();
vm.UserInput = "SomeInvalidText";
Assert.IsFalse(vm.UserInputIsValid);
}

In .NET 3.5, how can I determine which image is being displayed?

I tried this:
if(PauseButton.Image != global::GripAIConsole.Icons.Resume)
{
PauseButton.Image = global::GripAIConsole.Icons.Resume;
ToolTipMainWin.SetToolTip(PauseButton, "Resume / Step <F4>");
}
And it doesn't work. I would have thought it was comparing pointers internally to see if they were pointing at the same place.

You are working with resources, so if you want to make sure the reference is right, compare using the static method Object.ReferenceEquals(). As ChrisF said, you should not use this to determine application logic. Using a simple bool variable is much better (and slightly more performance friendly).

I would define the possible states with an enum:
public enum State {
Stopped,
Pausing,
Running
}
And then define a state property or variable:
State _state;
then Change the states as follows:
void ChangeState(State newState)
{
_state = newState;
switch (newState) {
case State.Stopped:
PauseButton.Image = global::GripAIConsole.Icons.Pause;
ToolTipMainWin.SetToolTip(PauseButton, "Start game <F5>");
break;
case State.Pausing:
PauseButton.Image = global::GripAIConsole.Icons.Resume;
ToolTipMainWin.SetToolTip(PauseButton, "Resume / Step <F4>");
break;
case State.Running:
PauseButton.Image = global::GripAIConsole.Icons.Pause;
ToolTipMainWin.SetToolTip(PauseButton, "Pause <F4> / Stop game <F6>");
break;
}
}
... or whatever your logic requires.
This is much cleaner and understandable. A picture has to do with the GUI, not with the logic. Inferring the state of the logic from things displayed on the forms is weird.

How to enforce constraints between decoupled objects?

Note - I have moved the original post to the bottom because I think it is still of value to newcomers to this thread. What follows directly below is an attempt at rewriting the question based on feedback.
Completely Redacted Post
Ok, I'll try to elaborate a bit more on my specific problem. I realise I am blending domain logic with interfacing/presentation logic a little but to be honest I am not sure where to seperate it. Please bear with me :)
I am writing an application that (among other things) performs logistics simulations for moving stuff around. The basic idea is that the user sees a Project, similar to Visual Studio, where she can add, remove, name, organise, annotate and so on various objects which I am about to outline:
Items and Locations are basic behaviourless data items.
class Item { ... }
class Location { ... }
A WorldState is a Collection of item-location pairs. A WorldState is mutable: The user is able to add and remove items, or change their location.
class WorldState : ICollection<Tuple<Item,Location>> { }
A Plan represents the movement of items to different locations at desired times. These can either be imported into the Project or generated within the program. It references a WorldState to get the initial location of various objects. A Plan is also mutable.
class Plan : IList<Tuple<Item,Location,DateTime>>
{
WorldState StartState { get; }
}
A Simulation then executes a Plan. It encapsulates a lot of rather complex behaviour, and other objects, but the end result is a SimulationResult which is a set of metrics that basically describe how much this cost and how well the Plan was fulfilled (think the Project Triangle)
class Simulation
{
public SimulationResult Execute(Plan plan);
}
class SimulationResult
{
public Plan Plan { get; }
}
The basic idea is that the users can create these objects, wire them together, and potentially re-use them. A WorldState may be used by multiple Plan objects. A Simulation may then be run over multiple Plans.
At the risk of being horribly verbose, an example
var bicycle = new Item();
var surfboard = new Item();
var football = new Item();
var hat = new Item();
var myHouse = new Location();
var theBeach = new Location();
var thePark = new Location();
var stuffAtMyHouse = new WorldState( new Dictionary<Item, Location>() {
{ hat, myHouse },
{ bicycle, myHouse },
{ surfboard, myHouse },
{ football, myHouse },
};
var gotoTheBeach = new Plan(StartState: stuffAtMyHouse , Plan : new [] {
new [] { surfboard, theBeach, 1/1/2010 10AM }, // go surfing
new [] { surfboard, myHouse, 1/1/2010 5PM }, // come home
});
var gotoThePark = new Plan(StartState: stuffAtMyHouse , Plan : new [] {
new [] { football, thePark, 1/1/2010 10AM }, // play footy in the park
new [] { football, myHouse, 1/1/2010 5PM }, // come home
});
var bigDayOut = new Plan(StartState: stuffAtMyHouse , Plan : new [] {
new [] { bicycle, theBeach, 1/1/2010 10AM }, // cycle to the beach to go surfing
new [] { surfboard, theBeach, 1/1/2010 10AM },
new [] { bicycle, thePark, 1/1/2010 1PM }, // stop by park on way home
new [] { surfboard, thePark, 1/1/2010 1PM },
new [] { bicycle, myHouse, 1/1/2010 1PM }, // head home
new [] { surfboard, myHouse, 1/1/2010 1PM },
});
var s1 = new Simulation(...);
var s2 = new Simulation(...);
var s3 = new Simulation(...);
IEnumerable<SimulationResult> results =
from simulation in new[] {s1, s2}
from plan in new[] {gotoTheBeach, gotoThePark, bigDayOut}
select simulation.Execute(plan);
The problem is when something like this is executed:
stuffAtMyHouse.RemoveItem(hat); // this is fine
stuffAtMyHouse.RemoveItem(bicycle); // BAD! bicycle is used in bigDayOut,
So basically when a user attempts to delete an item from a WorldState (and maybe the entire Project) via a world.RemoveItem(item) call, I want to ensure that the item is not referred to in any Plan objects which use that WorldState. If it is, I want to tell the user "Hey! The following Plan X is using this Item! Go and deal with that before trying to remove it!". The sort of behaviour I do not want from a world.RemoveItem(item) call is:
Deleting the item but still having the Plan reference it.
Deleting the item but having the Plan silently delete all elements in its list that refer to the item. (actually, this is probably desireable but only as a secondary option).
So my question is basically how can such desired behaviour be implemented with in a cleanly decoupled fashion. I had considered making this a purview of the user interface (so when user presses 'del' on an item, it triggers a scan of the Plan objects and performs a check before calling world.RemoveItem(item)) - but (a) I am also allowing the user to write and execute custom scripts so they can invoke world.RemoveItem(item) themselves, and (b) I'm not convinced this behaviour is a purely "user interface" issue.
Phew. Well I hope someone is still reading...
Original Post
Suppose I have the following classes:
public class Starport
{
public string Name { get; set; }
public double MaximumShipSize { get; set; }
}
public class Spaceship
{
public readonly double Size;
public Starport Home;
}
So suppose a constraint exists whereby a Spaceship size must be smaller than or equal to the MaximumShipSize of its Home.
So how do we deal with this?
Traditionally I've done something coupled like this:
partial class Starport
{
public HashSet<Spaceship> ShipsCallingMeHome; // assume this gets maintained properly
private double _maximumShipSize;
public double MaximumShipSize
{
get { return _maximumShipSize; }
set
{
if (value == _maximumShipSize) return;
foreach (var ship in ShipsCallingMeHome)
if (value > ship)
throw new ArgumentException();
_maximumShipSize = value
}
}
}
This is manageable for a simple example like this (so probably a bad example), but I'm finding as the constraints get larger and and more complex, and I want more related features (e.g. implement a method bool CanChangeMaximumShipSizeTo(double) or additional methods which will collect the ships which are too large) I end up writing more unnecessary bidirectional relationships (in this case SpaceBase-Spaceship is arguably appropriate) and complicated code which is largely irrelevant from the owners side of the equation.
So how is this sort of thing normally dealt with? Things I've considered:
I considered using events, similar to the ComponentModel INotifyPropertyChanging/PropertyChanging pattern, except that the EventArgs would have some sort of Veto() or Error() capability (much like winforms allows you to consume a key or suppress a form exit). But I'm not sure whether this constitutes eventing abuse or not.
Alternatively, managing events myself via an explicitly defined interface, e.g
asdf I need this line here or the formatting won't work
interface IStarportInterceptor
{
bool RequestChangeMaximumShipSize(double newValue);
void NotifyChangeMaximumShipSize(double newValue);
}
partial class Starport
{
public HashSet<ISpacebaseInterceptor> interceptors; // assume this gets maintained properly
private double _maximumShipSize;
public double MaximumShipSize
{
get { return _maximumShipSize; }
set
{
if (value == _maximumShipSize) return;
foreach (var interceptor in interceptors)
if (!RequestChangeMaximumShipSize(value))
throw new ArgumentException();
_maximumShipSize = value;
foreach (var interceptor in interceptors)
NotifyChangeMaximumShipSize(value);
}
}
}
But I'm not sure if this is any better. I'm also unsure if rolling my own events in this manner would have certain performance implications or there are other reasons why this might be a good/bad idea.
Third alternative is maybe some very wacky aop using PostSharp or an IoC/Dependency Injection container. I'm not quite ready to go down that path yet.
God object which manages all the checks and so forth - just searching stackoverflow for god object gives me the impression this is bad and wrong
My main concern is this seems like a fairly obvious problem and what I thought would be a reasonably common one, but I haven't seen any discussions about it (e.g. System.ComponentModel providse no facilities to veto PropertyChanging events - does it?); this makes me afraid that I've (once again) failed to grasp some fundamental concepts in coupling or (worse) object-oriented design in general.
Comments?
}

Based on the revised question:
I'm thinking the WorldState class needs a delegate... And Plan would set a method that should be called to test if an item is in use. Sortof like:
delegate bool IsUsedDelegate(Item Item);
public class WorldState {
public IsUsedDelegate CheckIsUsed;
public bool RemoveItem(Item item) {
if (CheckIsUsed != null) {
foreach (IsUsedDelegate checkDelegate in CheckIsUsed.GetInvocationList()) {
if (checkDelegate(item)) {
return false; // or throw exception
}
}
}
// Remove the item
return true;
}
}
Then, in the plan's constructor, set the delegate to be called
public class plan {
public plan(WorldState state) {
state.IsUsedDelegate += CheckForItemUse;
}
public bool CheckForItemUse(Item item) {
// Am I using it?
}
}
This is very rough, of course, I'll try to add more after lunch : ) But you get the general idea.
(Post-Lunch :)
The downside is that you have to rely on the Plan to set the delegate... but there's simply no way to avoid that. There's no way for an Item to tell how many references there are to it, or to control its own usage.
The best you can have is an understood contract... WorldState agrees not to remove an item if a Plan is using it, and Plan agrees to tell WorldState that it's using an item. If a Plan doesn't hold up its end of the contract, then it may end up in an invalid state. Tough luck, Plan, that's what you get for not following the rules.
The reason you don't use events is because you need a return value. An alternative would be to have WorldState expose a method to add 'listeners' of type IPlan, where IPlan defines CheckItemForUse(Item item). But you'd still have to rely that a Plan notifies WorldState to ask before removing an item.
One huge gap that I'm seeing: In your example, the Plan you create is not tied to the WorldState stuffAtMyHouse. You could create a Plan to take your dog to the beach, for example, and Plan would be perfectly happy (you'd have to create a dog Item, of course). Edit: do you mean to pass stuffAtMyHouse to the Plan constructor, instead of myHouse?
Because they're not tied, you currently don't care if you remove bicycle from stuffAtMyHouse... because what you're currently saying is "I don't care where the bicycle starts, and I don't care where it belongs, just take it to the beach". But what you mean (I believe) is "Take my bicycle from my house and go to the beach." The Plan needs to have a starting WorldState context.
TLDR: The best decoupling you can hope for is to let Plan choose what method WorldState should query before removing an item.
HTH,
James
Original Answer
It's not 100% clear to me what your goal is, and maybe it's just the forced example. Some possibilities:
I. Enforcing the maximum ship size on methods such as SpaceBase.Dock(myShip)
Pretty straight-forward... the SpaceBase tracks the size when called and throws a TooBigToDockException to the ship attempting to dock if it's too big. In this case, there's not really any coupling... you wouldn't notify the ship of the new max ship size, because managing the max ship size isn't the ship's responsibility.
If the max ship size decreases, you would force the ship to undock... again, the ship doesn't need to know the new max size (though an event or interface to tell it that it's now floating in space might be appropriate). The ship would have no say or veto on the decision... The base has decided it's too big and has booted it.
Your suspicions are correct... God objects are usually bad; clearly-delineated responsibilities make them vanish from the design in puffs of smoke.
II. A queryable property of the SpaceBase
If you want to let a ship ask you if it's too big to dock, you can expose this property. Again, you're not really coupled... you're just letting the ship make a decision to dock or not dock based on this property. But the base doesn't trust the ship to not-dock if it's too big... the base will still check on a call to Dock() and throw an exception.
The responsibility for checking dock-related constraints lies firmly with the base.
III. As true coupling, when the information is necessary to both parties
In order to dock, the base may need to control the ship. Here an interface is appropriate, ISpaceShip, which might have methods such as Rotate(), MoveLeft(), and MoveRight().
Here you avoid coupling by the virtue of the interface itself... Every ship will implement Rotate() differently... the base doesn't care, so long as it can call Rotate() and have the ship turn in place. A NoSuchManeuverException might be thrown by the ship if it doesn't know how to rotate, in which case the base makes a decision to try something different or reject the dock. The objects communicate, but they are not coupled beyond the Interface (contract), and the base still has the responsibility of docking.
IV. Validation on the MaxShipSize setter
You talk about throwing an exception to the caller if it tries to set the MaxShipSize to smaller than the docked ships. I have to ask, though, who is trying to set the MaxShipSize, and why? Either the MaxShipSize should have been set in the constructor and be immutable, or setting the size should follow natural rules, e.g. you can't set the ship size smaller than its current size, because in the real world you would expand a SpaceBase, but never shrink it.
By preventing illogical changes, you render the forced undocking and the communication that goes along with it moot.
The point I'm trying to make is that when you feel like your code is getting unnecessarily complicated, you're almost always right, and your first consideration should be the underlying design. And that in code, less is always more. When you talk about writing Veto() and Error(), and additional methods to 'collect ships that are too large', I become concerned that the code will turn into a Rube Goldberg machine. And I think that separated responsibilities and encapsulation will whittle away much of the unnecessary complication you're experiencing.
It's like a sink with plumbing issues... you can put in all sorts of bends and pipes, but the right solution is usually simple, straight-forward, and elegant.
HTH,
James

You know that a Spaceship must have a Size; put the Size in the base class, and implement validation checks in the accessor there.
I know this seems excessively focused on your specific implementation, but the point here is that your expectations aren't as decoupled as you expect; if you have a hard expectation in the base class of something in the derived class, your base class is making a fundamental expectation of the derived class providing an implementation of that; might as well migrate that expectation directly to the base class, where you can manage the constraints better.

You could do something like C++ STL traits classes - implement a generic SpaceBase<Ship, Traits> which has two parameterizing Types - one that defines the SpaceShip member, and the other that constrains the SpaceBase and its SpaceShips using a SpaceBaseTraits class to encapsulate the characteristics of the base such as limitations on ships it can contain.

The INotifyPropertyChanging interface was designed for data binding, which explains why it doesn't have abilities you're looking for. I might try something like this:
interface ISpacebaseInterceptor<T>
{
bool RequestChange(T newValue);
void NotifyChange(T newValue);
}

You want to apply constraints on actions, but applying them on the data.
Firstly, why changing Starport.MaximumShipSize is allowed? When we "resize" the Starport shouldn't all the Ships take off?
Those are the kind of questions to understand better what needs to be done (and there is no "right and wrong" answer, there is "mine and yours").
Look at the problem from other angle:
public class Starport
{
public string Name { get; protected set; }
public double MaximumShipSize { get; protected set; }
public AircarfDispatcher GetDispatcherOnDuty() {
return new AircarfDispatcher(this); // It can be decoupled further, just example
}
}
public class Spaceship
{
public double Size { get; private set; };
public Starport Home {get; protected set;};
}
public class AircarfDispatcher
{
Startport readonly airBase;
public AircarfDispatcher(Starport airBase) { this.airBase = airBase; }
public bool CanLand(Spaceship ship) {
if (ship.Size > airBase.MaximumShipSize)
return false;
return true;
}
public bool CanTakeOff(Spaceship ship) {
return true;
}
public bool Land(Spaceship ship) {
var canLand = CanLand(ship);
if (!canLand)
throw new ShipLandingException(airBase, this, ship, "Not allowed to land");
// Do something with the capacity of Starport
}
}
// Try to land my ship to the first available port
var ports = GetPorts();
var onDuty = ports.Select(p => p.GetDispatcherOnDuty())
.Where(d => d.CanLand(myShip)).First();
onDuty.Land(myShip);
// try to resize! But NO we cannot do that (setter is protected)
// because it is not the responsibility of the Port, but a building company :)
ports.First().MaximumShipSize = ports.First().MaximumShipSize / 2.0

Best practice for Undo Redo implementation in C# [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I need to implement Undo/Redo frame work for my window application(editor like powerpoint), what should be the best practice to follow, how would be handle all property changes of my objects and it reflection on UI.

There are two classic patterns to use. The first is the memento pattern which is used to store snapshots of your complete object state. This is perhaps more system intensive than the command pattern, but it allows rollback very simply to an older snapshot. You could store the snapshots on disk a la PaintShop/PhotoShop or keep them in memory for smaller objects that don't require persistence. What you're doing is exactly what this pattern was designed for, so it should fit the bill slightly better than the Command Pattern suggested by others.
Also, an additional note is that because it doesn't require you to have reciprocal commands to undo something that was previously done, it means that any potentially one way functions [such as hashing or encryption] which can't be undone trivially using reciprocal commands can still be undone very simply by just rolling back to an older snapshot.
Also as pointed out, the command pattern which is potentially less resource intensive, so I will concede that in specific cases where:
There is a large object state to be persisted and/or
There are no destructive methods and
Where reciprocal commands can be used very trivially to reverse any action taken
the command pattern may be a better fit [but not necessarily, it will depend very much on the situation]. In other cases, I would use the memento pattern.
I would probably refrain from using a mashup of the two because I tend to care about the developer that's going to come in behind me and maintain my code as well as it being my ethical responsibility to my employer to make that process as simple and inexpensive as possible. I see a mashup of the two patterns easily becoming an unmaintainable rat hole of discomfort that would be expensive to maintain.

There are three approaches here that are viable. Memento Pattern (Snapshots), Command Pattern and State Diffing. They all have advantages and disadvantages and it really comes down to your use case, what data you are working with and what you are willing to implement.
I would go with State Diffing if you can get away with it as it combines memory reduction with ease of implementation and maintainability.
I'm going to quote an article describing the three approaches (Reference below).
Note that VoxelShop mentioned in the article is open source. So you can take a look at the complexity of the command pattern here:
https://github.com/simlu/voxelshop/tree/develop/src/main/java/com/vitco/app/core/data/history
Below is an adapted excerpt from the article. However I do recommend that you read it in full.
Memento Pattern
Each history state stores a full copy. An action creates a new state and a pointer is used to move between the states to allow for undo and redo.
Pros
Implementation is independent of the applied action. Once implemented we can add actions without worrying about breaking history.
It is fast to advance to a predefined position in history. This is interesting when the actions applied between current and desired history position are computationally expensive.
Cons
Memory Requirements can be significantly higher compared to other approaches.
Loading time can be slow if the snapshots are large.
Command Pattern
Similar to the Memento Pattern, but instead of storing the full state, only the difference between the states is stored. The difference is stored as actions that can be applied and un-applied. When introducing a new action, apply and un-apply need to be implemented.
Pros
Memory footprint is small. We only need to store the changes to the model and if these are small, then the history stack is also small.
Cons
We can not go to an arbitrary position directly, but rather need to un-apply the history stack until we get there. This can be time consuming.
Every action and it's reverse needs to be encapsulated in an object. If your action is non trivial this can be difficult. Mistakes in the (reverse) action are really hard to debug and can easily result in fatal crashes. Even simple looking actions usually involve a good amount of complexity. E.g. in case of the 3D Editor, the object for adding to the model needs to store what was added, what color was currently selected, what was overwritten, if mirror mode active etc.
Can be challenging to implement and memory intensive when actions do not have a simple reverse, e.g when blurring an image.
State Diffing
Similar to the Command Pattern, but the difference is stored independent of the action by simply xor-nig the states. Introducing a new action does not require any special considerations.
Pros
Implementation is independent of the applied action. Once the history functionality is added we can add actions without worrying about breaking history.
Memory Requirements is usually much lower than for the Snapshot approach and in a lot of cases comparable to the Command Pattern approach. However this highly depends on the type of actions applied. E.g. inverting the color of an image using the Command Pattern should be very cheap, while State Diffing would save the whole image. Conversely when drawing a long free-form line, the Command Pattern approach might use more memory if it chained history entries for each pixel.
Cons / Limitations
We can not go to an arbitrary position directly, but rather need to un-apply the history stack until we get there.
We need to compute the diff between states. This can be expensive.
Implementing the xor diff between model states might be hard to implement depending on your data model.
Reference:
https://www.linkedin.com/pulse/solving-history-hard-problem-lukas-siemon

The classic practice is to follow the Command Pattern.
You can encapsulate any object that performs an action with a command, and have it perform the reverse action with an Undo() method. You store all the actions in a stack for an easy way of rewinding through them.

Take a look at the Command Pattern.
You have to encapsulate every change to your model into separate command objects.

I wrote a really flexible system to keep track of changes. I have a drawing program which implements 2 types of changes:
add/remove a shape
property change of a shape
Base class:
public abstract class Actie
{
public Actie(Vorm[] Vormen)
{
vormen = Vormen;
}
private Vorm[] vormen = new Vorm[] { };
public Vorm[] Vormen
{
get { return vormen; }
}
public abstract void Undo();
public abstract void Redo();
}
Derived class for adding shapes:
public class VormenToegevoegdActie : Actie
{
public VormenToegevoegdActie(Vorm[] Vormen, Tekening tek)
: base(Vormen)
{
this.tek = tek;
}
private Tekening tek;
public override void Redo()
{
tek.Vormen.CanRaiseEvents = false;
tek.Vormen.AddRange(Vormen);
tek.Vormen.CanRaiseEvents = true;
}
public override void Undo()
{
tek.Vormen.CanRaiseEvents = false;
foreach(Vorm v in Vormen)
tek.Vormen.Remove(v);
tek.Vormen.CanRaiseEvents = true;
}
}
Derived class for removing shapes:
public class VormenVerwijderdActie : Actie
{
public VormenVerwijderdActie(Vorm[] Vormen, Tekening tek)
: base(Vormen)
{
this.tek = tek;
}
private Tekening tek;
public override void Redo()
{
tek.Vormen.CanRaiseEvents = false;
foreach(Vorm v in Vormen)
tek.Vormen.Remove(v);
tek.Vormen.CanRaiseEvents = true;
}
public override void Undo()
{
tek.Vormen.CanRaiseEvents = false;
foreach(Vorm v in Vormen)
tek.Vormen.Add(v);
tek.Vormen.CanRaiseEvents = true;
}
}
Derived class for property changes:
public class PropertyChangedActie : Actie
{
public PropertyChangedActie(Vorm[] Vormen, string PropertyName, object OldValue, object NewValue)
: base(Vormen)
{
propertyName = PropertyName;
oldValue = OldValue;
newValue = NewValue;
}
private object oldValue;
public object OldValue
{
get { return oldValue; }
}
private object newValue;
public object NewValue
{
get { return newValue; }
}
private string propertyName;
public string PropertyName
{
get { return propertyName; }
}
public override void Undo()
{
//Type t = base.Vorm.GetType();
PropertyInfo info = Vormen.First().GetType().GetProperty(propertyName);
foreach(Vorm v in Vormen)
{
v.CanRaiseVeranderdEvent = false;
info.SetValue(v, oldValue, null);
v.CanRaiseVeranderdEvent = true;
}
}
public override void Redo()
{
//Type t = base.Vorm.GetType();
PropertyInfo info = Vormen.First().GetType().GetProperty(propertyName);
foreach(Vorm v in Vormen)
{
v.CanRaiseVeranderdEvent = false;
info.SetValue(v, newValue, null);
v.CanRaiseVeranderdEvent = true;
}
}
}
With each time Vormen = the array of items that are submitted to the change.
And it should be used like this:
Declaration of the stacks:
Stack<Actie> UndoStack = new Stack<Actie>();
Stack<Actie> RedoStack = new Stack<Actie>();
Adding a new shape (eg. Point)
VormenToegevoegdActie vta = new VormenToegevoegdActie(new Vorm[] { NieuweVorm }, this);
UndoStack.Push(vta);
RedoStack.Clear();
Removing a selected shape
VormenVerwijderdActie vva = new VormenVerwijderdActie(to_remove, this);
UndoStack.Push(vva);
RedoStack.Clear();
Registering a property change
PropertyChangedActie ppa = new PropertyChangedActie(new Vorm[] { (Vorm)e.Object }, e.PropName, e.OldValue, e.NewValue);
UndoStack.Push(ppa);
RedoStack.Clear();
Finally the Undo/Redo action
public void Undo()
{
Actie a = UndoStack.Pop();
RedoStack.Push(a);
a.Undo();
}
public void Redo()
{
Actie a = RedoStack.Pop();
UndoStack.Push(a);
a.Redo();
}
I think this is the most effective way of implementing a undo-redo algorithm.
For an example, look at this page on my website: DrawIt.
I implemented the undo redo stuff at around line 479 of the file Tekening.cs. You can download the source code. It can be implemented by any kind of application.