Command Pattern Experiments in Rust

I've been doing some experiments in using the command pattern in Rust and found at least two ways to write it.

But first... Why?

There is one thing I'm trying to do in which the command pattern fits perfectly: I want to have a library with all the actions and then plug interfaces on top of, being either a CLI interface or a Web interface or whatever interface. For that, the logic behind the action should be somewhat isolated from whatever source it is calling it.

What It Is

The Command Pattern is described as having one object for each action ('cause, you know, the patterns focused more on OO designs) and each of those have an execute method which... well... execute the command.

The Enum Solution

As what you have is a list of actions, one of the ideas was to use Enums, even if it is not exactly what the pattern describes.

Say, we have two actions can be called: deposit money and withdraw money. Simple.

So one could have the following Enum¹:

enum Command {
    Deposit(Decimal),
    Withdraw(Decimal),
}

Because Rust allows enum variants to carry a value with them, the amount to be deposited/withdraw is attached directly to the variant.

And then you have the execute() function. And, again, 'cause Rust allows adding functions to almost everything, what I did was add a method in the Enum:

impl Command {
    fn execute(&self) -> Result<...> {
        match self {
            Deposit(value) => do_the_deposit(value),
            Withdraw(value) => withdraw_money(value),
        }
    }
}

... and so on.

To use it, I put something pretty close to this in my interface layer:

let value = incoming_external_request.value()
let command = match incoming_external_request.command() {
    "deposit" => Command::Deposit(value),
    "withdraw" => Command::Withdraw(value),
}
command.execute();

It feels fine and all, but it tends to make a mess with the amount of content that goes in or around the impl, in my opinion. But, at the same time, the dispatch layer (between the service/enum layer and the interface layer) is pretty basic.

One solution to the amount of "content in or around impl" could be use multiple impl: So I could have a module deposit.rs which impls the do_the_deposit and another module withdraw.rs which also impls inside the enum with the withdraw_money content. But I'd still need the center execute to do the proper "dispatch" of the calls.

The Trait Solution

The trait solution is very close to what the pattern is: You create a trait (interface) and "impl" it for all the commands, which are just structs. For example:

trait Command {
    fn execute(&self) -> Result<...>;
}

struct Deposit(Decimal);
impl Command for Deposit {
    fn execute(&self) -> Result<...> {
        // what was `do_the_deposit` now goes here.
    }
}

struct Withdraw(Decimal);
impl Command for Withdraw {
    fn execute(&self) -> Result<...> {
        // what was `withdraw_money` now goes here.
    }
}

... which feels a bit cleaner, since all related things to Deposit or Withdraw are now tied together.

However, this causes a slight problem with the interface layer: Now it can't just return one sized thing: It needs to return a dynamic dispatchable content, like Box<dyn Command>, which isn't as pretty as the direct Enum/Struct/sized content.

On the other hand, since Box implements Deref, once the interface throws something-that-implements-Command, one could just call execute() directly on it.

let command = interface_that_returns_a_box_dyn_command();
command.execute();

Where I see those two

I can see the Enum being used for simple, single domain architectures. Since all things are related, they can reside correctly under the Enum.

But when dealing with multiple domains, the trait/dynamic dispatch feels more at home: Related things get into their own module, in their own space and the idea of mixing them (for example, if you have a money domain and a tag domain, and you want to tag money operations) goes on layer above.