Software Design

Strategy vs Template Method vs Command: Differences

Have you ever had this moment while studying design patterns?

4 min read
Cover image for Strategy vs Template Method vs Command: Differences

Have you ever had this moment while studying design patterns?

“What’s the difference between Strategy and Template Method? And why is Command in the mix?”

All three feel like swapping behavior, so they’re easy to confuse.

Here’s the key point.

Strategy replaces the entire algorithm,

Template Method keeps the skeleton fixed and changes only some steps,

Command wraps an action to execute later.

Once you remember that, half the battle is over. Today, we’ll clearly distinguish these three patterns with code.


How are the three patterns different at a glance?

Let’s start with the big picture in a table.

Category Strategy Pattern Template Method Command Pattern
Core idea Replace the entire algorithm Fixed skeleton, replace some steps Wrap an action as an object
Reuse mechanism Composition (delegation) Inheritance Composition (delegation)
Replacement time Runtime Compile time (inheritance) Runtime
Typical concern “How should it be calculated?” “The order is the same, but the details differ” “When and what should execute?”

This is why the three patterns are confusing.

They all aim to separate the parts that change.

But their methods and purposes differ. Let’s break them down.


Strategy replaces the entire algorithm

Strategy creates independent objects for multiple ways to perform the same task and swaps them as needed.

Payment methods are a good example.

Card payment, KakaoPay, bank transfer. The task—payment—is the same, but the method differs.

Strategy swaps the entire algorithm
Strategy uses a structure that swaps the entire algorithm
protocol PayStrategy {
    func pay(_ amount: Int) -> String
}
struct CardPay: PayStrategy {
    func pay(_ amount: Int) -> String { "Pay by card \(amount)" }
}
struct KakaoPay: PayStrategy {
    func pay(_ amount: Int) -> String { "Pay with KakaoPay \(amount)" }
}

var strategy: PayStrategy = CardPay()
print(strategy.pay(10000))
// Output: Pay by card 10000

The key is that changing the strategy variable to KakaoPay() at runtime replaces the behavior entirely.

The point is delegation through composition, not inheritance.

Writing the payment strategy code makes delegation immediately clear
After writing the payment strategy code, the delegation structure becomes clear

Template Method keeps the skeleton and changes only parts

Template Method is slightly different.

The order of the overall flow is fixed, while subclasses fill in only certain steps.

Think of cooking ramen: boil water → add ingredients → finish. The order stays the same, but the ingredient step changes.

class Ramen {
    func cook() {           // This is Template Method
        boilWater()
        addIngredients()    // Replace only this step in the subclass
        print("Done!")
    }
    func boilWater() { print("Boil the water") }
    func addIngredients() { print("Basic ingredients") }
}
class CheeseRamen: Ramen {
    override func addIngredients() { print("Add cheese") }
}
CheeseRamen().cook()
// Output: Boil the water / Add cheese / Done!

The decisive differences from Strategy are that it uses inheritance and changes only some steps, not the whole algorithm.

The parent class controls the flow (cook).


Command wraps the action itself

Command has an entirely different concern from the previous two.

The goal isn’t how to calculate something, but to turn an action into an object that can be executed, canceled, or queued later.

A remote-control button is an easy analogy. It stores the command “turn on the light” as an object and executes it when pressed.

protocol Command { func execute() }
struct LightOn: Command {
    func execute() { print("Turn on the light") }
}

let button: Command = LightOn()
button.execute()   // I decide when to execute it
// Output: Turn on the light

Because the request is wrapped in an object, undo, logging, and work queues fit naturally.

Strategy chooses a method; Command stores and manages a request.


When to use—and when to avoid them

In practice, I choose based on these criteria.

  • Strategy Pattern: Use when multiple algorithms serve the same purpose and must be swapped at runtime (sorting methods, discount policies, payment methods)
  • Template Method: Use when the processing order is always the same but some steps differ (data-parsing flows, game-turn progression)
  • Command: Use when execution must be deferred or canceled, redone, or queued (undo, job schedulers)

There are also signs that you should avoid them.

If there are only two or three branches and they won’t grow, don’t force a pattern. A simple if is easier to read.

Template Method is especially tied to inheritance, so when flexibility matters, it’s safer to consider Strategy (composition) first.


Interview questions often look like this

Q. What is the biggest difference between Strategy and Template Method?

Strategy swaps the entire algorithm at runtime through composition (delegation), while Template Method fixes the skeleton through inheritance and overrides only some steps. Strategy offers flexibility; Template Method excels at controlling the flow.

Q. How does Command differ from Strategy?

Strategy focuses on choosing how to perform an operation, while Command wraps the request itself as an object, enabling undo, queuing, and logging. The distinction is algorithm selection versus request management.


Although the three patterns look similar, they become distinct when you focus on what is separated and why.

Strategy is the method, Template Method is the blank in the sequence, and Command is the request itself. Remember those three words and they’ll be much easier to distinguish. Happy studying!