You have a boss, who doesn’t care who will be doing some work or how it will be done, he just want it to be started and completed at some point of time, say after customer signed contract. Since you are at high position you were asked to form team A that will be working at some project X, you also got list of high-level requirements from your boss. You should be ready to start all work at the moment your customer signs contract.

COMMAND

So you are Command – you encapsulate receiver team A and parameters to start work (project and requirements). Team and requirements are given to you by your boss – Client.

You are able to delegate all work to team A and provide requirements at the moment customer triggers process. Your customer is Invoker, they have contact to you, so can use you as they want.

Command – is design pattern that allows us encapsulate request, tune it with parameters as needed and then execute at one point of time, without knowing how actually executes work.

Client code

Here is how story looks from code perspective. Taking a look at client code (boss):

            var customer = new Customer();

// for some reason boss always knows that company has money
// only for team Z
var team = new Team("Z");
// he also managed to get high-level list of requirements for you
var requirements = new List<Requirement>() { new Requirement("Cool web site"), new Requirement("Ability to book beer on site") };
// you should be ready to be invoked by Customer
ICommand commandX = new YouAsProjectManagerCommand(team, requirements);

customer.AddCommand(commandX);

// there is also here developer who can code at light speed
var heroDeveloper = new HeroDeveloper();
// boss decided to give him project A
ICommand commandA = new HeroDeveloperCommand(heroDeveloper, "A");

customer.AddCommand(commandA);

// when customer signs contract with boss
// your team and hero developer start executing their job
customer.SignContractWithBoss();

Command

Now lets take a look on two concrete commands:

    public interface ICommand
{
void Execute();
}


public class YouAsProjectManagerCommand : ICommand
{
public YouAsProjectManagerCommand(Team team, List<Requirement> requirements)
{
Team = team;
Requirements = requirements;
}

public void Execute()
{
// implementation delegates work to concrete receiver
Team.CompleteProject(Requirements);
}

protected Team Team { get; set; }
protected List<Requirement> Requirements { get; set; }
}

public class HeroDeveloperCommand : ICommand
{
public HeroDeveloperCommand(HeroDeveloper heroDeveloper, string projectName)
{
HeroDeveloper = heroDeveloper;
ProjectName = projectName;
}

protected HeroDeveloper HeroDeveloper { get; set; }
public string ProjectName { get; set; }

public void Execute()
{
// implementation delegates work to concrete receiver
HeroDeveloper.DoAllHardWork(ProjectName);
}
}

Receiver

Team and HeroDeveloper are receivers of work that should be done.

Invoker

Customer simply aggregates many commands and without knowing how those commands were built by boss. Customer as true invoker simply triggers work using Execute method:

    public class Customer
{
public Customer()
{
Commands = new List<ICommand>();
}

public void AddCommand(ICommand command)
{
Commands.Add(command);
}

protected List<ICommand> Commands { get; set; }

public void SignContractWithBoss()
{
foreach (var command in Commands)
{
command.Execute();
}
}
}

Output

User Story (Cool web site) has been completed

User Story (Ability to book beer on site) has been completed

Hero developer completed project (A) without requirements in manner of couple of hours!

UPDATE: Nov 18, 2010

UML-Diagram

Here below I added diagram showing two commands exactly as in example. Please take into account that for simplicity you can remove one pair HeroDeveloperCommand-HereDeveloper. Also take into consideration that in our example concrete commands are aggregating receivers, but this is not common situation. In most cases receiver is some another system.

image