It can be tricky to tell these three apart because, structurally, they all rely on composition (holding a reference to another object) rather than inheritance. However, their intents—the specific problems they are trying to solve—are completely different.
To know which one to choose, you need to look at the core anxiety of your current system. What is the specific thing that is changing or causing pain?
The Decision Matrix
Here is a quick cheat sheet based on what you are trying to accomplish:
| If your primary problem is… | …You are looking at the… | Think of it as… |
|---|---|---|
| Choosing how to do one specific task from a menu of options. | Strategy Pattern | A swappable tool. |
| Telling other parts of the system that something just happened. | Observer Pattern | A broadcasting station. |
| Combining a bunch of optional, stackable behaviors together. | Decorator Pattern | Layers of an onion. |
Look for these triggers in your code
1. When to use STRATEGY: “I have one goal, but multiple ways to achieve it.”
Look at your code. Do you see a massive if/else or switch block inside a single method that changes how an operation is run based on a configuration or state?
- The Trigger: You find yourself thinking: “Right now I need to do X, but tomorrow the client might want me to do X using a completely different algorithm.”
- Real-World Examples: * A checkout system that needs to calculate shipping (but shipping changes if it’s FedEx, UPS, or DHL).
- A text exporter that can save a file as PDF, Plain Text, or Markdown.
- Key Phrase: “Swap the guts.” You aren’t changing the identity of the object; you are just changing its internal algorithm.
2. When to use OBSERVER: “When X happens, Y, Z, and W need to react.”
Look for places where one object is forced to know too much about unrelated systems just to keep them updated. If your Order class contains references to EmailService, InventorySystem, and ShippingDashboard just to call them when an order completes, your code is too tightly coupled.
- The Trigger: You find yourself thinking: “This object shouldn’t care who is listening to it, it just needs to scream ‘I’m done!’ into the void, and let whoever cares take action.”
- Real-World Examples:
- A stock market tracker where multiple UI graphs need to update the millisecond a price changes.
- A YouTube channel (Subject) notifying all of its subscribers (Observers) when a new video drops.
- Key Phrase: “Don’t call us, we’ll call you.”
3. When to use DECORATOR: “I need to dynamically layer features on top of a core object.”
Look for a class explosion or a massive list of boolean flags in a constructor (e.g., hasMilk=true, hasSugar=false, isLarge=true). If you try to use inheritance to solve every possible permutation of a product or service, you’ll go crazy.
- The Trigger: You find yourself thinking: “I have a core object, but the user can add combinations of features A, B, and C in any order they want, and I need to calculate the result dynamically.”
- Real-World Examples:
- A text window that can optionally have a vertical scrollbar, a horizontal scrollbar, and a border.
- Encryption/Compression streams: Writing data to a file, but optionally encrypting it first, and optionally compressing it before that.
- Key Phrase: “Wrap it up.” ---
A Combined Scenario
To really solidify this, imagine building a Video Game:
- You create an
Enemycharacter. When they attack, they can use a sword, a bow, or magic. Because you want to easily change their weapon at runtime, you use the Strategy Pattern for theirAttackBehavior. - As the player fights the enemy, the enemy takes damage. When their health hits zero, the UI needs to update, the sound effects engine needs to play a death groan, and the quest log needs to mark an objective complete. You use the Observer Pattern so the enemy can just broadcast
onDeath()without hardcoding the UI, sound, or quest systems into the enemy class. - Later, the enemy drinks a potion. Suddenly they are Invisible, Poisoned, and Shielded all at once. Instead of writing a
PoisonedInvisibleShieldedEnemyclass, you wrap the base enemy in behavior decorators using the Decorator Pattern.