Strategy Design Pattern in Java with Real Example
Master the Strategy Design Pattern in Java with real-life examples like payment methods and game behavior. Learn to switch algorithms at runtime easily.
Strategy Design Pattern

The Strategy Design Pattern is a behavioral pattern that helps you define a group of algorithms, keep each one in a separate class, and switch between them while the program is running.
Real-Life Examples
Payments

The image above shows a checkout page where a customer is entering their details to buy a product.
One important thing here is the payment method — how the user chooses to pay. We support multiple ways to pay, like Card, GPay, and PayPal.
Depending on the option selected by the user, a different pay() method is used.
- If the user selects GPay, the
pay()method will handle GPay payment. - If they select Card, then card payment logic will be used.
So basically, we are creating multiple versions of pay(), and using the correct one based on what the user picks.
Game Character

Imagine you're playing a game where the main character is a wizard. By default, the wizard throws fireballs.
The game has special power-ups that change how the wizard attacks:
-
If you take the fire power-up, the wizard throws fireballs.
-
If you take the lightning power-up, the wizard throws lightning.
-
If you take the ice power-up, the wizard freezes enemies.
So depending on what power-up the player takes, the attack() behavior changes during the game.
In both examples above, the behavior (pay() or attack()) is decided at runtime. That’s exactly what the Strategy Pattern helps with — switching behavior while the program is running without changing the code structure.
What Happens Without Strategy Pattern?
If we don’t use this pattern where it’s needed, we can run into a big problem called class explosion.
Let’s understand this with a simple example.
Suppose we have a Robot class. This robot can do three things:
-
move()– how the robot moves -
speak()– how the robot communicates -
attack()– how the robot attacks
Each behavior has 3 different styles:
| Behavior | Strategy Options |
|---|---|
| Move | Walk, Fly, Run |
| Speak | Beep, Speak, Silent |
| Attack | Punch, Laser, Sword |
If we use Strategy Pattern:
We create just 9 classes for each behavior:
-
Move Strategies:
WalkStrategy,FlyStrategy,RunStrategy -
Speak Strategies:
BeepStrategy,SpeakStrategy,SilentStrategy -
Attack Strategies:
PunchStrategy,LaserStrategy,SwordStrategy
This means: If I want a robot that can Run, be Silent, and attack with a Laser, I simply inject the 3 strategies into the robot.
If I want a robot that can Walk, Speak, and Punch, I just plug in those strategies.
This gives us flexibility with only 9 strategy classes.
If we don’t use Strategy Pattern:
We have to create every possible combination of these behaviors in advance.
Total classes = move types × speak types × attack types = 3 × 3 × 3 = 27 robot classes!
That's 27 classes just for 3 behaviors with 3 options each. Imagine what happens when we add more! This mess of too many classes is called Class Explosion, and it's a maintenance nightmare.
UML Diagram

This UML diagram shows how the pattern works:
-
IStrategyis the main interface. -
Concrete strategies like
CreditCardPayment,GPayPayment,PayPalPaymentimplement it. -
The
Contextclass holds a reference to a strategy and uses it to perform an action. -
The client chooses and sets the strategy at runtime.