I need to execute several commands in a specific order but before I excute the main command, another command needs to be executed first and in some situations there are more commands that also need to be executed last.To achieve this I build an extended chain of resposibility. It does not only have a post-command but also a pre-command. The main command in the middle is the one that a user sees in a menu.internal abstract class Command{    public Command Pre { get; set; }    public Command Post { get; set; }    public int Execute()    {        var executedCommandCount = 0;        if (Pre != null)        {            var preResult = Pre.Execute();            if (preResult == 0) { return executedCommandCount; }            executedCommandCount += preResult;        }        if (!ExecuteCore())        {            return executedCommandCount;        }        executedCommandCount++;        if (Post != null)        {            var postResult = Post.Execute();            if (postResult == 0) { return executedCommandCount; }            executedCommandCount += postResult;        }        return executedCommandCount;    }    protected abstract bool ExecuteCore();}Test commands:class FirstCommand : Command{    protected override bool ExecuteCore()    {        return true;    }}class MainCommand : Command{    protected override bool ExecuteCore()    {        return true;    }}class LastCommand : Command{    protected override bool ExecuteCore()    {        return true;    }}Example:var mainCommand = new MainCommand{    Pre = new FirstCommand(),    Post = new LastCommand()};var executedCommandCount = mainCommand.Execute(); // 3
Chain of commands
c#;design patterns
Why not implement WPF's ICommand? That way you could use them in command bindings, and if you're not using WPF, you could still attach them to click handlers and use their CanExecute method to determine whether to enable or disable a menu item.It's not immediately obvious why a command's Execute method would return anything. Having a parameterized command (like ICommand has) could be used to eliminate the need for that bool return value. It's not clear what the int value might be used for either (other than debugging?).The setters for Pre and Post should be protected IMO; they have no business on the type's public interface.The null checks indicate that not all implementations actually need a Pre or a Post command: to me this is starting to smell a bit.Seems a more robust and flexible design would be a simple ICommand with decorators - here over a classic DelegateCommand base class implementing ICommand:public class PreExecuteCommandDecorator : DelegateCommand{    private readonly DelegateCommand _command;    private readonly Action<object> _action;    public PreExecuteCommandDecorator(DelegateCommand command, Action<object> action)    {        _command = command;        _action = action;    }    public override bool CanExecute(object parameter)    {        return _command.CanExecute(parameter);    }    public override void ExecuteCore(object parameter)    {        _action.Invoke(parameter);        _command.Execute(parameter);    }}Similarly:public class PostExecuteCommandDecorator : DelegateCommand{    private readonly DelegateCommand _command;    private readonly Action<object> _action;    public PostExecuteCommandDecorator(DelegateCommand command, Action<object> action)    {        _command = command;        _action = action;    }    public override bool CanExecute(object parameter)    {        return _command.CanExecute(parameter);    }    public override void ExecuteCore(object parameter)    {        _command.Execute(parameter);        _action.Invoke(parameter);    }}That way you could build your chain of command in a much cleaner way IMO - especially if you're building an actual chain with pre-commands that have their own pre and post commands that have their own pre and post commands that have their own pre... well you get the idea.