Understanding Object-Oriented Programming (OOP) and the top design patterns can revolutionize your development journey.
From ensuring one instance of a class to dynamically creating objects and enhancing their behavior, these patterns will empower you to write cleaner, more flexible, and maintainable code.
So, start applying and take advantages of these design patterns in your projects!
Summary
Design Patterns | Description | Use Case |
Singleton Pattern | Ensures that there is only one instance of a class in the entire system. | - Have only one of something in your system. - Share a common resource or configuration. -Control access to a global resource. |
Factory Pattern | Creates objects without showing the complicated creation process to the user. | - Create different objects without knowing their specific classes. - Common way to create objects of a related family. - Hide the complex creation logic from the client code. |
Observer Pattern | Establishes a connection between objects so that when one object changes, all other connected objects get automatically notified and updated. | - Stay updated about changes in a system. -Keep multiple objects in sync. - Establish dynamic relationships between objects. - Support event-driven systems. |
Strategy Pattern | Defines different strategies (ways of doing things) and allows you to switch between them easily. | - Have different ways to solve a problem or perform a task. - Switch between different strategies dynamically. - Keep the code flexible and extensible. |
Decorator Pattern | Adds extra features to an object without changing its original structure. | -Add new functionalities to an object dynamically. - Enhance an object's behavior without modifying its original code. -Avoid having too many subclasses for different combinations of features. |
Understanding Object-Oriented Programming (OOP)
Before we delve into design patterns, let’s briefly understand the fundamentals of Object-Oriented Programming (OOP).
In OOP, you structure your code around objects that represent real-world entities. These objects have properties (attributes) and behaviors (methods).
OOP focuses on encapsulation, inheritance, and polymorphism to organize and reuse code effectively.
CheckOut!
Learn more about the top 9 OOP concepts that every developers should familiar with.
Discover the top 10 most common OOP abusers to avoid repeating the mistakes.
The Power of Design Patterns
Design patterns are like proven recipes for solving common programming problems. They provide reusable solutions that have been refined and tested over time.
By incorporating design patterns into your coding practices, you can benefit from the expertise of experienced developers and write code that is more efficient, maintainable, and scalable.
Now, let’s explore the top five OOP design patterns that will elevate your development skills.
1. Singleton Pattern: Ensuring One Instance
The Singleton pattern ensures that there is only one instance (object) of a class throughout your program. It’s useful in scenarios where you need a single point of access to a shared resource.
Example
Trading system
Music Player
Trading system
Imagine you have a stock trading system where you need to keep track of the current market price for a specific stock. You want to ensure that there is only one instance responsible for fetching and providing the latest market price throughout your trading application
In this scenario, the Singleton pattern can be utilized to ensure there is a single instance of a `StockPriceProvider` class that fetches and stores the current market price.
Here’s a simplified implementation of the Singleton pattern for a stock price provider:
class StockPriceProvider:
__instance = None
latest_price = None
@staticmethod
def get_instance():
if StockPriceProvider.__instance is None:
StockPriceProvider.__instance = StockPriceProvider()
return StockPriceProvider.__instance
def fetch_latest_price(self, symbol):
# Simulated logic to fetch the latest market price for the given stock symbol
# In a real implementation, this would involve querying an API or a database
self.latest_price = self._simulate_fetching_latest_price(symbol)
def _simulate_fetching_latest_price(self, symbol):
# Simulated method to fetch the latest price
# Replace this with your actual logic to fetch the price
price = 0.0
if symbol == "AAPL":
price = 150.25
elif symbol == "GOOGL":
price = 2750.50
elif symbol == "AMZN":
price = 3500.75
return price
def get_latest_price(self):
return self.latest_price
Now, let’s see how we can use the Singleton stock price provider in a trading application:
price_provider = StockPriceProvider.get_instance()
price_provider.fetch_latest_price("AAPL")
# In another part of the trading application...
latest_price = StockPriceProvider.get_instance().get_latest_price()
print(f"The latest price for AAPL is: ${latest_price}")
In the above example, the `get_instance()` method ensures that only one instance of the `StockPriceProvider` class exists.
You can fetch the latest price using the `fetch_latest_price()` method, which would simulate the process of fetching the price from an external source like an API or a database.
The `get_latest_price()` method retrieves the latest price stored in the singleton instance.
Music Player
Imagine you’re building a music player application, and you want to have a class that handles playing the music. You don’t want multiple instances of the player playing different songs simultaneously.
Instead, you want a single instance that controls the playback throughout the entire application. That’s where the singleton pattern can be helpful.
class MusicPlayer:
instance = None
def __init__(self):
if MusicPlayer.instance is not None:
raise Exception("Only one instance of MusicPlayer allowed!")
MusicPlayer.instance = self
self.current_song = None
self.is_playing = False
@staticmethod
def get_instance():
if MusicPlayer.instance is None:
MusicPlayer()
return MusicPlayer.instance
def play_song(self, song):
self.current_song = song
self.is_playing = True
print("Now playing:", self.current_song)
def stop_song(self):
self.current_song = None
self.is_playing = False
print("Playback stopped.")
In this updated example, the `MusicPlayer` class is a singleton. It ensures that only one instance of the `MusicPlayer` class exists in the application.
To use the singleton, you would do something like this:
player = MusicPlayer.get_instance()
player.play_song("Song A") # Output: Now playing: Song A
another_player = MusicPlayer.get_instance()
another_player.play_song("Song B") # Output: Now playing: Song B
player.stop_song() # Output: Playback stopped.
In this case, both `player` and `another_player` are references to the same instance of the `MusicPlayer` class.
So, when you play a song or stop the playback using one reference, it affects the state of the singleton instance, and the changes are reflected when using the other reference.
2. Factory Pattern: Creating Objects Dynamically
The Factory pattern provides a centralized way to create objects, abstracting the complex creation process. It allows you to create objects without explicitly specifying their classes, providing flexibility and decoupling your code.
Example
Trading
Game character
Trading
Imagine you are building a trading platform where users can trade various financial instruments like stocks, bonds, and cryptocurrencies. Each instrument has its own unique properties and behaviors.
You want to create these trading instruments dynamically based on the user’s selection without tightly coupling your code to each specific instrument class. The Factory pattern can help you achieve this.
Here’s a simplified example of implementing the Factory pattern for creating trading instruments:
class Instrument:
def __init__(self, symbol):
self.symbol = symbol
def execute_trade(self):
pass
class Stock(Instrument):
def execute_trade(self):
print(f"Executing stock trade for {self.symbol}")
class Bond(Instrument):
def execute_trade(self):
print(f"Executing bond trade for {self.symbol}")
class Cryptocurrency(Instrument):
def execute_trade(self):
print(f"Executing cryptocurrency trade for {self.symbol}")
class InstrumentFactory:
@staticmethod
def create_instrument(instrument_type, symbol):
if instrument_type == "stock":
return Stock(symbol)
elif instrument_type == "bond":
return Bond(symbol)
elif instrument_type == "cryptocurrency":
return Cryptocurrency(symbol)
# Usage:
instrument_factory = InstrumentFactory()
instrument_type = input("Enter instrument type (stock/bond/cryptocurrency): ")
symbol = input("Enter instrument symbol: ")
instrument = instrument_factory.create_instrument(instrument_type, symbol)
instrument.execute_trade()
In the above example, we have a base `Instrument` class with derived classes `Stock`, `Bond`, and `Cryptocurrency`, representing different types of trading instruments.
The `InstrumentFactory` class acts as the factory, responsible for creating the desired instrument based on the requested type.
When the user enters the instrument type and symbol, the factory’s `create_instrument()` method dynamically creates the corresponding instrument object.
You can then perform actions, such as `execute_trade()`, on the created instrument without having to know its specific class.
The Factory pattern allows for flexible creation of trading instruments without tightly coupling the code to individual classes.
Game character
Imagine you are building a game where you have different types of characters, such as warriors, mages, and archers. Each character has its own set of abilities and characteristics.
Now, you want to create these characters dynamically based on the player’s choice without tightly coupling your code to each specific character class. That’s where the Factory pattern comes in handy.
Here’s a simplified example of implementing the Factory pattern for creating game characters:
class Character:
def __init__(self, name):
self.name = name
def attack(self):
pass
class Warrior(Character):
def attack(self):
print(f"{self.name} swings their mighty sword!")
class Mage(Character):
def attack(self):
print(f"{self.name} casts a powerful spell!")
class Archer(Character):
def attack(self):
print(f"{self.name} shoots arrows with precision!")
class CharacterFactory:
@staticmethod
def create_character(character_type, name):
if character_type == "warrior":
return Warrior(name)
elif character_type == "mage":
return Mage(name)
elif character_type == "archer":
return Archer(name)
# Usage:
character_factory = CharacterFactory()
character_type = input("Enter character type (warrior/mage/archer): ")
character_name = input("Enter character name: ")
character = character_factory.create_character(character_type, character_name)
character.attack()
We have a base `Character` class with derived classes `Warrior`, `Mage`, and `Archer`, each representing a specific character type. The `CharacterFactory` class acts as the factory, responsible for creating the desired character based on the requested type.
When the player enters the character type and name, the factory’s `create_character()` method dynamically creates the appropriate character object. You can then perform actions, such as `attack()`, on the created character without explicitly knowing its specific class.
The Factory pattern allows you to decouple the creation of objects from the code that uses them. It provides a centralized way to create objects dynamically based on specific inputs, such as user choices or configuration settings.
This flexibility simplifies the codebase and allows for easy extensibility when adding new character types or variations in the future.
Remember, the Factory pattern acts as a creator, dynamically producing objects based on specific inputs, without tightly coupling the code to individual classes.
3. Observer Pattern: Notifying State Changes
The Observer design pattern is a behavioral design pattern in software development.
It defines a one-to-many relationship between objects, where changes in one object, known as the subject or publisher, notify and automatically update other objects, known as observers or subscribers, that depend on it.
In simpler terms, the Observer design pattern allows multiple objects to be notified and updated automatically when a specific object’s state changes.
Think of a YouTube channel with subscribers. When a YouTuber uploads a new video, all the subscribers receive a notification. The YouTuber is the “subject” who produces updates, and the subscribers are the “observers” who want to be notified of the updates.
Example
Social media
sport game
Trading
Social media
Imagine you have a social media app where users can follow their favorite celebrities. Whenever a celebrity makes a new post, all the followers should be notified instantly.
The Observer pattern can help achieve this by allowing the followers to subscribe to updates from the celebrities they follow.
Here’s a simplified example of implementing the Observer pattern for our social media app:
class Celebrity:
def __init__(self, name):
self.name = name
self.followers = []
def add_follower(self, follower):
self.followers.append(follower)
def remove_follower(self, follower):
self.followers.remove(follower)
def notify_followers(self, post):
for follower in self.followers:
follower.update(post)
class Follower:
def __init__(self, name):
self.name = name
def update(self, post):
print(f"{self.name} received a new post: {post}")
# Usage:
celebrity = Celebrity("SuperStar")
follower1 = Follower("John")
follower2 = Follower("Sarah")
celebrity.add_follower(follower1)
celebrity.add_follower(follower2)
celebrity.notify_followers("Check out my new photo!")
celebrity.remove_follower(follower2)
celebrity.notify_followers("I just posted a new video!")
In the above example, we have a `Celebrity` class representing the celebrity or subject. The `Follower` class represents the followers or observers who want to be notified of the celebrity’s updates.
The celebrity maintains a list of followers and can add or remove followers as needed. When the celebrity makes a new post, the `notify_followers()` method is called, which loops through the followers and calls their `update()` method to notify them of the new post.
Using the Observer pattern, the celebrity and the followers are decoupled, allowing the celebrity to make posts without needing to know who the followers are. The followers can also subscribe and unsubscribe from multiple celebrities as they wish.
In our example, when the celebrity adds a follower and then makes a new post, all the followers receive the update. When a follower is removed, they no longer receive future updates.
sport game
Imagine you have a sports game with a scoreboard that displays the score to the audience. Whenever the score changes during the game, you want the scoreboard to update automatically without having to manually refresh it.
Here’s a simplified example of implementing the Observer pattern for updating a scoreboard:
class Scoreboard:
def __init__(self):
self.score = 0
self.observers = []
def add_observer(self, observer):
self.observers.append(observer)
def remove_observer(self, observer):
self.observers.remove(observer)
def update_score(self, new_score):
self.score = new_score
self.notify_observers()
def notify_observers(self):
for observer in self.observers:
observer.update(self.score)
class Audience:
def update(self, score):
print(f"The score is now {score}")
# Usage:
scoreboard = Scoreboard()
audience1 = Audience()
audience2 = Audience()
scoreboard.add_observer(audience1)
scoreboard.add_observer(audience2)
scoreboard.update_score(10)
scoreboard.update_score(20)
In the above example, the `Scoreboard` class represents the subject, while the `Audience` class represents the observer. The scoreboard keeps track of the score and maintains a list of observers.
When the score changes, it notifies all the registered observers by calling their `update()` method
The `Audience` class’s `update()` method receives the updated score as a parameter and performs any necessary actions, such as displaying the new score to the audience.
By using the Observer pattern, the scoreboard can automatically inform the audience about score updates without the need for manual refreshing or checking. This promotes loose coupling between the scoreboard and the observers, allowing them to evolve independently.
Trading
Imagine you have a trading platform where users can monitor the real-time prices of different stocks.
Whenever the price of a stock changes, you want to notify the subscribed users automatically without them having to continuously refresh the page. The Observer pattern can help you achieve this.
Think of a stock market where investors subscribe to receive price change notifications for specific stocks. Whenever the price of a subscribed stock changes, the investors are notified automatically without needing to constantly monitor the market.
Here’s a simplified example of implementing the Observer pattern for notifying trade updates:
class Stock:
def __init__(self, symbol):
self.symbol = symbol
self.price = 0.0
self.observers = []
def add_observer(self, observer):
self.observers.append(observer)
def remove_observer(self, observer):
self.observers.remove(observer)
def update_price(self, new_price):
self.price = new_price
self.notify_observers()
def notify_observers(self):
for observer in self.observers:
observer.update(self.symbol, self.price)
class Investor:
def __init__(self, name):
self.name = name
def update(self, symbol, price):
print(f"{self.name}: {symbol} price is now {price}")
# Usage:
stock = Stock("AAPL")
investor1 = Investor("John")
investor2 = Investor("Sarah")
stock.add_observer(investor1)
stock.add_observer(investor2)
stock.update_price(150.25)
stock.update_price(151.50)
In the above example, the `Stock` class represents the subject, while the `Investor` class represents the observer. Each stock object keeps track of its symbol, price, and a list of observers.
When the price changes, it notifies all the registered observers by calling their `update()` method.
The `Investor` class’s `update()` method receives the updated stock symbol and price as parameters and performs any necessary actions, such as displaying the updated price to the investor.
By using the Observer pattern, the stock object can automatically inform the subscribed investors about price updates without the need for continuous manual refreshing.
This promotes loose coupling between the stocks and the investors, allowing them to stay updated on their chosen stocks without actively monitoring the market.
4. Strategy Pattern: Flexible Behavior
The Strategy pattern allows you to dynamically change the behavior (strategy) of an object at runtime. It enables you to encapsulate different algorithms or behaviors into separate classes, making your code more flexible and reusable.
Example
Payment
RPG game
Payment
Imagine you’re building an online shopping system where customers can choose different payment methods, such as credit card or PayPal.
The Strategy design pattern is like having different strategies for making payments based on the chosen payment method.
class PaymentStrategy:
def pay(self, amount):
raise NotImplementedError()
class CreditCardStrategy(PaymentStrategy):
def pay(self, amount):
# Implement credit card payment logic
class PayPalStrategy(PaymentStrategy):
def pay(self, amount):
# Implement PayPal payment logic
class ShoppingCart:
def __init__(self, payment_strategy):
self.payment_strategy = payment_strategy
def process_payment(self, amount):
self.payment_strategy.pay(amount)
In the example above, we define a PaymentStrategy interface with a `pay()` method.
The CreditCardStrategy and PayPalStrategy classes implement this interface with their own payment logic. The ShoppingCart class uses a payment strategy to process payments.
By providing different payment strategies, you can easily switch between different payment methods (e.g., credit card, PayPal) without modifying the ShoppingCart class.
RPG game
Imagine you are a game developer creating a role-playing game (RPG) where players can choose different character classes, such as warrior, mage, or archer. Each class has its own unique set of abilities and fighting styles.
Now, you want to implement a system that allows players to dynamically switch between different fighting strategies based on their chosen class without changing the overall game structure. That’s where the Strategy pattern comes in.
To explain this concept in simple terms, let’s use a relatable example. Think of a pizza restaurant where you can choose different pizza toppings.
The restaurant offers various strategies for topping customization, such as “Build Your Own Pizza” or “Signature Pizza.” Depending on your preference, you can select the strategy that suits you best without changing the way the pizza is made.
Here’s a simplified example of implementing the Strategy pattern for character fighting strategies in a game:
class Character:
def __init__(self, name, fighting_strategy):
self.name = name
self.fighting_strategy = fighting_strategy
def attack(self):
self.fighting_strategy.attack()
class FightingStrategy:
def attack(self):
pass
class WarriorStrategy(FightingStrategy):
def attack(self):
print("Swinging a mighty sword!")
class MageStrategy(FightingStrategy):
def attack(self):
print("Casting a powerful spell!")
class ArcherStrategy(FightingStrategy):
def attack(self):
print("Shooting arrows with precision!")
# Usage:
warrior = Character("Brave Warrior", WarriorStrategy())
mage = Character("Mystic Mage", MageStrategy())
archer = Character("Stealthy Archer", ArcherStrategy())
warrior.attack() # Outputs: Swinging a mighty sword!
mage.attack() # Outputs: Casting a powerful spell!
archer.attack() # Outputs: Shooting arrows with precision!
In the above example, we have a `Character` class representing the game character. The character has a name and a fighting strategy, which is an instance of a specific `FightingStrategy` class.
The `FightingStrategy` class is the base class for different fighting strategies. Each derived class, such as `WarriorStrategy`, `MageStrategy`, and `ArcherStrategy`, implements the `attack()` method according to the specific fighting style.
When a character performs an attack, the `attack()` method of its associated strategy is called. This allows characters to dynamically switch between different fighting strategies, enabling flexible behavior based on their chosen class.
By using the Strategy pattern, the game can accommodate various character classes without requiring major changes to the overall game structure. Each class can have its own fighting strategy, and the behavior can be easily customized and extended by adding new strategy classes.
5. Decorator Pattern: Enhancing Objects Dynamically
The Decorator pattern allows you to dynamically add new functionalities (decorators) to an object without changing its core structure. It’s useful when you want to add features to an object dynamically and avoid creating an explosion of subclasses.
The Decorator pattern is a design pattern that allows you to enhance or extend the functionality of an object dynamically without the need to modify its underlying structure.
It follows the principle of open-closed design, where you can add new behaviors or features to an object without altering its original code.
Example
Coffee Shop
Trading
Coffee Shop
Imagine you have a coffee shop where customers can order different types of coffee, such as espresso, latte, or cappuccino.
Customers can also choose additional toppings or flavors, such as whipped cream, caramel syrup, or vanilla extract. The Decorator pattern allows you to enhance the base coffee object with these extra options dynamically.
Here’s a simplified example of implementing the Decorator pattern for enhancing a coffee object:
In the above example, the `Coffee` class represents the base coffee object. The `SimpleCoffee` class is a concrete implementation of the base coffee. It provides the basic description and cost of a simple coffee.
The `CoffeeDecorator` class is an abstract decorator that inherits from the `Coffee` class. It wraps around other concrete coffee objects, allowing you to dynamically add new behaviors.
The `MilkDecorator` and `CaramelDecorator` classes are concrete decorators. They extend the functionality of the base coffee or previous decorators by adding their own descriptions and costs.
You can use the decorators to enhance the coffee object dynamically:
coffee = SimpleCoffee()
print(coffee.get_description()) # Output: Simple coffee
print(coffee.get_cost()) # Output: 1.0
coffee_with_milk = MilkDecorator(coffee)
print(coffee_with_milk.get_description()) # Output: Simple coffee, milk
print(coffee_with_milk.get_cost()) # Output: 1.5
coffee_with_milk_and_caramel = CaramelDecorator(coffee_with_milk)
print(coffee_with_milk_and_caramel.get_description()) # Output: Simple coffee, milk, caramel
print(coffee_with_milk_and_caramel.get_cost()) # Output: 2.25
Trading
Imagine you have a trading platform where users can execute various types of trades, such as stocks, bonds, and commodities. The Decorator design pattern is like adding additional functionalities or features to the trades without modifying the core trading logic.
Let’s consider a scenario where you have a `Trade` class that represents a basic trade. You want to add additional features to the trade, such as stop loss or take profit functionality, without modifying the original class.
Here’s a simplified code demonstration:
class Trade:
def execute(self):
return "Executing trade"
class TradeDecorator:
def __init__(self, trade):
self.trade = trade
def execute(self):
return self.trade.execute()
class StopLossDecorator(TradeDecorator):
def execute(self):
return self.trade.execute() + " with stop loss"
class TakeProfitDecorator(TradeDecorator):
def execute(self):
return self.trade.execute() + " with take profit"
# Usage
basic_trade = Trade() # Create a basic trade
trade_with_stop_loss = StopLossDecorator(basic_trade) # Add stop loss functionality to the trade
trade_with_take_profit = TakeProfitDecorator(basic_trade) # Add take profit functionality to the trade
trade_with_both_features = TakeProfitDecorator(StopLossDecorator(basic_trade)) # Add both stop loss and take profit features
print(basic_trade.execute()) # Output: Executing trade
print(trade_with_stop_loss.execute()) # Output: Executing trade with stop loss
print(trade_with_take_profit.execute()) # Output: Executing trade with take profit
print(trade_with_both_features.execute()) # Output: Executing trade with stop loss with take profit
In this code, the `Trade` class represents the basic trade. Each decorator class, such as `StopLossDecorator` and `TakeProfitDecorator`, wraps the original trade object using composition.
The decorator classes inherit from `TradeDecorator` and override the `execute` method to add their specific functionality while preserving the original behavior of the trade.
By combining different decorators, you can create trades with various combinations of features without modifying the original `Trade` class.
Remember, the Decorator pattern enables you to enhance objects dynamically by adding new behaviors or features without modifying their original structure.
It’s like customizing a coffee with different toppings or flavors, allowing customers to enjoy personalized drinks without changing the base coffee recipe.
Conclusion
You’ve explored the top five OOP design patterns that can transform your development skills.
By understanding and implementing these patterns, you’ll become a more proficient and efficient developer. These patterns empower you to write cleaner, more maintainable, and flexible code.
So, embrace the power of design patterns and take your coding journey to new heights!
Go Further!
- freecodecamp: The 3 Types of Design Patterns All Developers Should Know
- LearningDaily.dev: The 7 Most Important Software Design Patterns
Â
FAQs
Object-Oriented Programming (OOP) design patterns are reusable solutions to common programming problems. They help you write cleaner, more organized, and maintainable code.
Design patterns provide proven solutions to common problems, saving developers time and effort. They improve code readability, maintainability, and flexibility. Additionally, design patterns promote better collaboration among developers.
No, design patterns are not language-specific. They can be applied to any programming language that supports object-oriented programming principles.
Yes, beginners can benefit from learning and using design patterns. They provide a structured approach to problem-solving and improve code quality.
It’s not necessary to memorize all design patterns. Understanding the concepts and principles behind each pattern is more important. Reference materials and resources are available whenever you need them.
The Singleton pattern ensures that there is only one instance of a class in the system, making it useful for scenarios where you need to have a single point of access to a shared resource or when you want to control access to a global resource.
The Factory pattern abstracts the process of object creation, allowing you to create different objects without knowing their specific classes. It provides a common interface to create objects of a related family, hiding the complex creation logic from the client code.
The Observer pattern helps you maintain consistency between related objects and keeps them in sync. It allows objects to establish dynamic relationships, so when one object changes, all the connected objects get automatically notified and updated.
The Strategy pattern allows you to define a family of algorithms and switch between them dynamically. It provides flexibility by separating the implementation details of algorithms from the client code, making it easier to change or extend the behavior of an object at runtime.
The Decorator pattern is useful when you want to add new features or functionalities to an object dynamically without modifying its original structure.
It helps avoid having a large number of subclasses for different combinations of behaviors and allows you to enhance an object’s behavior without altering its core implementation.
No, the purpose of the Singleton pattern is to ensure that there is only one instance of a class in the entire system. It restricts the instantiation of a class to a single object.
The Factory pattern provides a flexible and extensible way to create different types of objects. By adding new classes that inherit from the same factory interface, you can easily introduce new object types without modifying the existing client code.
Yes, the Observer pattern is often used in event-driven systems. It allows objects (observers) to subscribe to events or changes in other objects (subject) and get automatically notified, similar to subscribing to events and receiving notifications in event-driven programming.
Yes, that’s one of the main benefits of the Strategy pattern. It allows you to switch between different strategies dynamically, enabling the client to select and use the most suitable strategy based on specific requirements or conditions.
The Decorator pattern provides an alternative to subclassing for extending the functionality of an object.
Unlike subclassing, which creates a new class for each combination of features, the Decorator pattern allows you to add features dynamically at runtime by wrapping the object with one or more decorator classes.
