Blog

Proxy Design Pattern is a Structural Design Pattern that allows us to provide a substitute or we can say a placeholder for another object. In Proxy Design Pattern, a class represents the functionality of another class. A proxy receives client requests, does some work (access control, caching, etc.) and then passes the request to a service object (the original object).

Proxy Design Pattern is used when we need to create a wrapper for an object to control access to it. It is also used to add additional functionality to an object without changing its code.

Take the following example. In the image, the man at the gate talks to visitors for the queen because she’s busy. He passes messages and only lets the right ones in — kind of like a helper who speaks for her. That’s what a proxy does.

Types of Proxy Design Pattern

Following are the different types of Proxy Design Pattern −

• Remote Proxy − Lets you use something that’s far away, maybe on another computer.
• Virtual Proxy − Creates the real thing only when you actually need it, so it saves time and memory.
• Protection Proxy − Checks if you’re allowed to use something before giving you access.
• Caching Proxy − Stores results and gives them back quickly if you ask for the same thing again.
• Logging Proxy − Keeps a record of what happens when you use the real object.
• Synchronization Proxy − Makes sure only one person can use something at a time to avoid clashes.
• Smart Reference Proxy − Adds a few extra steps when you use something, like counting how many times it’s used or loading it only when needed.

Components of Proxy Design Pattern

• Subject − The basic rules or actions that both the real object and the helper use.
• RealSubject − The real object that does the main job.
• Proxy − The helper that talks for the real object and controls who can use it.

Implementation of Proxy Design Pattern in C++

We will implement a simple example of Proxy Design Pattern in C++. In this example, we will create a proxy for a Database class that simulates a connection to a database. The proxy will control access to the database and add caching functionality.

Steps to Implement Proxy Design Pattern

Follow the steps below to implement the Proxy Design Pattern in C++

• Define the Subject interface that declares the common operations for both the real object and the proxy.
• Create the RealSubject class that implements the Subject interface and simulates a database connection.
• Create the Proxy class that also implements the Subject interface and controls access to the RealSubject. It will add caching functionality.
• Use the Proxy class in the client code to access the database.

C++ Code for Proxy Design Pattern

Below is the C++ code that demonstrates the Proxy Design Pattern −

Here, the DatabaseProxy class acts as a middleman for the RealDatabase class. It saves the result of the first query and gives back the saved result if you ask again, showing how a proxy can cache data.

#include <iostream>#include <string>usingnamespace std;// Subject InterfaceclassDatabase{public:virtual string query(const string& sql)=0;virtual~Database(){}};// RealSubject ClassclassRealDatabase:public Database{public:
   string query(const string& sql)override{// Simulate a database queryreturn"Results for query: "+ sql;}};// Proxy ClassclassDatabaseProxy:public Database{private:
   RealDatabase* realDatabase;
   string cachedResult;bool isCached;public:DatabaseProxy():realDatabase(nullptr),isCached(false){}
   string query(const string& sql)override{if(!isCached){if(realDatabase ==nullptr){
            realDatabase =newRealDatabase();}
         cachedResult = realDatabase->query(sql);
         isCached =true;}else{
         cout <<"Returning cached result."<< std::endl;}return cachedResult;}~DatabaseProxy(){delete realDatabase;}};// Client Codeintmain(){
   Database* db =newDatabaseProxy();// First query - will access the real database
   cout << db->query("SELECT * FROM users")<< endl;// Second query - will return cached result
   cout << db->query("SELECT * FROM users")<< endl;delete db;return0;}

Following is the output of the above code −

Results for query: SELECT * FROM users
Returning cached result.
Results for query: SELECT * FROM users

Pros and Cons of Proxy Design Pattern

Following are the advantages and disadvantages of using the Proxy Design Pattern −

When to Use Proxy Design Pattern?

Following are some scenarios where you might want to use the Proxy Design Pattern −

• Control who can use something.
• Add saving results or keeping records without changing the main object.
• Delay making the real thing until it is needed.
• Keep something safe from people who shouldn’t use it.
• Manage how and when something is used.

Real-World Applications of Proxy Design Pattern

Following are some real-world applications of the Proxy Design Pattern −

Conclusion

In this chapter, you learned what the Proxy Design Pattern is, how it works, and where you can use it. Proxy helps you control access to something and lets you add new features without changing the main object. It’s a handy way to keep things safe and organized.

The Command Design Pattern is a way to turn a request—like asking a light to turn on—into its own object. This means you can treat actions as things you can pass around, save for later, or even undo if you want.

In simple terms, it lets you wrap up an action and all the details it needs, so you can run it whenever you like. This makes your code more flexible and easier to manage, especially when you want to add features like undo or keep a history of what happened.

For example, in a text editor, actions like Copy, Paste, and Undo can each be their own command object. This makes it easy to run them, line them up, or take them back if you change your mind.

In the following image, you can see a remote control sending commands to a light source. The remote control (Invoker) doesn’t know how the Light (Receiver) works; it just tells it to turn on or off using Command objects.

Components of Command Design Pattern

Following are the main components of the Command Design Pattern −

• Command − This is just an interface or abstract class with a method like execute(). It’s a common way to say, “Here’s what a command should look like.”
• ConcreteCommand − These are the actual command classes. Each one does something specific, like turning a light on or off. They know which object to work with and what action to perform.
• Client − This is the part of your code that puts everything together. It creates the command objects and tells them which things they should control.
• Invoker − Think of this as the remote control. It doesn’t know what the command does, it just knows how to ask the command to do its job.
• Receiver − This is the real worker. It’s the object that actually does the work when a command is executed, like the light that turns on or off.

C++ Implementation of Command Design Pattern

In this we will implement a simple command pattern example where we have a light that can be turned on and off using command objects.

Steps to Implement Command Design Pattern in C++

Following are the steps to implement Command Design Pattern in C++

• First, make an interface (or abstract class) for your commands, with a method like execute().
• Next, create classes for each command (like turning a light on or off) that implement this interface.
• Then, make a class for the thing you want to control (for example, a Light class that knows how to turn itself on or off).
• After that, create an “invoker” class (like a remote control) that will use the command objects to do the work.
• Finally, in your main code, put everything together: make the commands, connect them to the thing they control, and use the invoker to run them.

C++ Code Example of Command Design Pattern

Following is a simple C++ code example demonstrating the Command Design Pattern −

#include <iostream>usingnamespace std;// Command InterfaceclassCommand{public:virtualvoidexecute()=0;};// Receiver ClassclassLight{public:voidon(){
       cout <<"Light is ON"<< endl;}voidoff(){
       cout <<"Light is OFF"<< endl;}};// Concrete Command to turn on the lightclassLightOnCommand:public Command{private:
   Light* light;public:LightOnCommand(Light* l):light(l){}voidexecute()override{
         light->on();}};// Concrete Command to turn off the lightclassLightOffCommand:public Command{private:
   Light* light;public:LightOffCommand(Light* l):light(l){}voidexecute()override{
         light->off();}};// Invoker ClassclassRemoteControl{private:
   Command* command;public:voidsetCommand(Command* cmd){
      command = cmd;}voidpressButton(){
      command->execute();}};// Client Codeintmain(){
   Light* light =newLight();

   Command* lightOn =newLightOnCommand(light);
   Command* lightOff =newLightOffCommand(light);

   RemoteControl* remote =newRemoteControl();// Turn the light ON
   remote->setCommand(lightOn);
   remote->pressButton();// Turn the light OFF
   remote->setCommand(lightOff);
   remote->pressButton();// Clean updelete light;delete lightOn;delete lightOff;delete remote;return0;}

Following is the output of the above code −

Light is ON
Light is OFF

In this example, we have defined a Command interface with an execute method. The Light class acts as the Receiver that knows how to turn the light on and off. The LightOnCommand and LightOffCommand classes are ConcreteCommand classes that implement the Command interface. The RemoteControl class is the Invoker that calls the command to execute the request. Finally, in the main function, we create instances of the commands and use the RemoteControl to execute them.

Pros and Cons of Command Design Pattern

Real-World Use Cases of Command Design Pattern

• In graphical user interfaces, handling actions like clicking buttons or selecting menu items.
• Adding undo and redo features in programs such as text editors or drawing tools.
• Creating systems that schedule tasks to run later, like job queues.
• Controlling smart home devices with a remote or app.
• Recording and playing back a series of actions as macros in software.

Conclusion

In this chapter, we learned what is commnand design pattern, its components, and how to implement it in C++. We also discussed the pros and cons of using this pattern along with real-world use cases. The Command Design Pattern is a powerful tool for decoupling the sender and receiver of requests, it enables features like undo/redo, and improves code organization.

A decorator is a Structural Design Pattern that allows us to add new functionalities to an existing object without changing or disturbing its structure. It lets us attach new behaviors to an object by placing that object inside another special wrapper object that contains the new behavior.

Let’s understand in detail with an example. Imagine you have a simple text editor application with basic text features like writing and saving or editing text. Now, your manager wants you to add some new features like spell checking and grammar checking. If you are using the Decorator Design Pattern, you can easily add these new features without changing the existing code of the text editor. You can create separate decorator classes for spell checking and grammar checking that wrap around the original text editor class.

Components of Decorator Design Pattern

There are four main components of Decorator Design Pattern, as shown in the following image. Also, the client is the one who uses these components to perform operations. We have added two

Let’s understand each of these components in detail −

• Component − This is an interface or abstract class that defines the common methods for both the concrete component and the decorators. In our example, this would be the interface for the text editor.
• Concrete Component − This is the class that implements the component interface and represents the original object that we want to add new functionalities to. In our example, this would be the basic text editor class.
• Decorator − This is an abstract class that also implements the component interface and has a reference to a component object. The decorator class is responsible for adding new functionalities to the component object. In our example, this would be the abstract decorator class for the text editor.
• Concrete Decorators − These are the classes that extend the decorator class and implement the new functionalities. In our example, these would be the spell checker and grammar checker classes that add their respective functionalities to the text editor.

Implementation of Decorator Design Pattern in C++

Earlier, we discussed the components of the Decorator Design Pattern. Now, let’s see how we can implement it in C++.

In this implementation, we will create a simple Music Player application where we have a basic music player that can play music. We will then create decorators to add new functionalities like Shuffle and Repeat to the music player.

Steps to Implement Decorator Design Pattern

Let’s see how we can implement the Decorator Design Pattern in C++

• Create a Component interface for the music player.
• Implement a Concrete Component class for the basic music player.
• Create an abstract Decorator class that implements the Component interface.
• Implement two concrete Decorator classes for shuffle and repeat functionalities.
• Create a Client class to use the music player with decorators.

C++ Code for Decorator Design Pattern

Let’s look at the C++ code for the Decorator Design Pattern implementation of a Music Player application.

Here we will use all the components of the Decorator Design Pattern that we discussed earlier. We will create a Component interface for the music player, a Concrete Component class for the basic music player, an abstract Decorator class that implements the Component interface, and concrete Decorator classes for shuffle and repeat functionalities.

#include <iostream>usingnamespace std;// ComponentclassMusicPlayer{public:virtualvoidplay()=0;virtual~MusicPlayer(){}};// Concrete ComponentclassBasicMusicPlayer:public MusicPlayer{public:voidplay(){
      cout <<"Playing music..."<< endl;}};// DecoratorclassMusicPlayerDecorator:public MusicPlayer{protected:
   MusicPlayer* player;public:MusicPlayerDecorator(MusicPlayer* p):player(p){}virtualvoidplay(){
      player->play();}virtual~MusicPlayerDecorator(){delete player;}};// Concrete Decorator for ShuffleclassShuffleDecorator:public MusicPlayerDecorator{public:ShuffleDecorator(MusicPlayer* p):MusicPlayerDecorator(p){}voidplay(){
      cout <<"Shuffling playlist..."<< endl;
      player->play();}};// Concrete Decorator for RepeatclassRepeatDecorator:public MusicPlayerDecorator{public:RepeatDecorator(MusicPlayer* p):MusicPlayerDecorator(p){}voidplay(){
      cout <<"Repeating current song..."<< endl;
      player->play();}};// Clientintmain(){
   MusicPlayer* player =newBasicMusicPlayer();
   MusicPlayer* shufflePlayer =newShuffleDecorator(player);
   MusicPlayer* repeatShufflePlayer =newRepeatDecorator(shufflePlayer);

   cout <<"Basic Music Player:"<< endl;
   player->play();

   cout <<"\nMusic Player with Shuffle:"<< endl;
   shufflePlayer->play();

   cout <<"\nMusic Player with Shuffle and Repeat:"<< endl;
   repeatShufflePlayer->play();delete repeatShufflePlayer;// This will also delete shufflePlayer and playerreturn0;}

Following is the output of the above code −

Basic Music Player:
Playing music...

Music Player with Shuffle:
Shuffling playlist...
Playing music...

Music Player with Shuffle and Repeat:
Repeating current song...
Shuffling playlist...
Playing music...

Pros and Cons of Decorator Design Pattern

The following table highlights the pros and cons of using the Decorator Design Pattern −

When to Use Decorator Design Pattern?

Following are some scenarios where you should consider using the Decorator Design Pattern −

• To add more functionalities to an object dynamically.
• When you want to avoid class explosion due to multiple combinations of features.
• To stick to the Single Responsibility Principle by dividing functionalities into separate classes.
• For adding responsibilities to individual objects without affecting other objects of the same class.
• To enhance the behavior of an object at runtime.

Real-world Applications of Decorator Design Pattern

The following image illustration some of real-world applications of Decorator Design Pattern –

Conclusion

In this chapter, we learned about the Decorator Design Pattern, its components, implementation steps, and a C++ code example. We also discussed the pros and cons of using this pattern, when to use it, and some real-world applications. The Decorator Design Pattern is a powerful tool that allows us to add new functionalities to existing objects without changing their structure, which in turn makes it easy for us to maintain and extend our program codes.

Composite Design Pattern is a structural design pattern that allows you to compose objects into tree like structures that represent part-whole hierarchies. This pattern lets clients treat any individual object and a composition of objects uniformly.

Sounds complicated? Let’s break it down with an example.

• Suppose you are building a graphic design application which allows users to create and manipulate various shapes like circles, rectangles, and lines.
• You also want to allow user to group the shapes together to form new designs(like a house made of rectangles and triangles, or a tree made of circles and lines).
• With the Composite Design Pattern, you can treat both individual shapes and groups of shapes uniformly. This means that you can perform operations like move, resize, or draw on both single shapes and groups of shapes without worrying about their specific types.

Components of Composite Design Pattern

The Composite Pattern is made up of multiple components. Take a look at the following image. Here, we can see the four main components of the Composite Design Pattern. The Component is an interface that has common methods for both Leaf and Composite. The Leaf is like a loner who doesn’t have any children, while the Composite is like a parent who can have multiple children (which can be either Leaf or other Composite). And, lastly we have the Client, which is like the boss who interacts with the Component interface to perform operations on both Leaf and Composite.

Implementation of Composite Design Pattern in C++

Now, that we understand the components of the Composite Design Pattern, let’s see how we can implement it in C++.

In this implementation, we will implement a simple File System where we have Files and Directories. A File is a Leaf and a Directory is a Composite that can contain multiple Files and other Directories.

Steps to Implement Composite Design Pattern

Let’s look at the steps to implement the File System using the Composite Design Pattern in C++:

First, create a Component interface that has all the common methods. Next, create a Leaf class that implements the Component interface. Then, create a Composite class that also implements the Component interface and has a list to store its children. Finally, create a Client class that interacts with the Component interface to perform operations on both Leaf and Composite.

The code in image is just for representation purpose. The complete code is given below.

C++ Code for Composite Design Pattern

In this code, we will define a FileSystemComponent interface that has a method showDetails(). The File class implements this interface and represents a leaf node in the file system. The Directory class also implements the FileSystemComponent interface and represents a composite node that can contain multiple children (both files and directories).

Following is the complete C++ code for the Composite Design Pattern implementation of a File System −

#include <iostream>#include <vector>#include <memory>usingnamespace std;// ComponentclassFileSystemComponent{public:virtualvoidshowDetails()=0;};// LeafclassFile:public FileSystemComponent{private:
   string name;public:File(string fileName):name(fileName){}voidshowDetails(){
      cout <<"File: "<< name << endl;}};//  Composite classDirectory:public FileSystemComponent{private:
   string name;
   vector<shared_ptr<FileSystemComponent>> children;public:Directory(string dirName):name(dirName){}voidadd(shared_ptr<FileSystemComponent> component){
      children.push_back(component);}voidshowDetails(){
      cout <<"Directory: "<< name << endl;for(auto child : children){
         child->showDetails();}}};// Clientintmain(){
   shared_ptr<FileSystemComponent> file1 =make_shared<File>("File1.txt");
   shared_ptr<FileSystemComponent> file2 =make_shared<File>("File2.txt");
   shared_ptr<FileSystemComponent> dir1 =make_shared<Directory>("Dir1");
   shared_ptr<FileSystemComponent> dir2 =make_shared<Directory>("Dir2");

   dir1->add(file1);
   dir2->add(file2);
   dir2->add(dir1);

   dir2->showDetails();return0;}

Following is the output of the above code −

Directory: Dir2
File: File2.txt
Directory: Dir1
File: File1.txt

Advantages and Disadvantages of Composite Design Pattern

Following are the advantages and disadvantages of using the Composite Design Pattern −

When to Use Composite Design Pattern?

You should consider using the Composite Design Pattern in the following scenarios −

• When you have a part-whole hierarchy in your application.
• To represent tree structures, such as file systems or organizational hierarchies.
• For treating individual objects and compositions of objects uniformly.
• While simplifying client code by allowing it to interact with a single interface.
• To add new types of components without changing existing code.
• When you want to manage complex structures more easily.
• Performing operations on both individual objects and groups of objects.

Real World Examples of Composite Design Pattern

Following are some real-world examples of the Composite Design Pattern −

Conclusion

In this chapter, we learned about the Composite Design Pattern, its components, implementation in C++, advantages, disadvantages, and when to use it. The Composite Design Pattern is a useful tool for managing complex structures and hierarchies in software development. By using this pattern, we can simplify our code and make it more easy to maintain and also extend in the future.

Bridge Design Pattern is a structural design pattern which helps to separate the following two aspects of a software system −

• Abstraction − Provides the interface for client code, hiding the implementation details.
• Implementation − Provides the concrete implementation of the abstraction.

By separating the above aspects, we can make both the abstraction and implementation independently expandable. This means that we can add new abstractions and implementations without affecting existing code.

Think of it like a Coffee shop. You love coffee but alone it would be plain. Sometimes you want Espresso, sometimes Latte, and sometimes you want to add Milk, Sugar, or Honey.

The coffee type (Espresso, Latte) is the abstraction, and the add-ons (Milk, Sugar, Honey) are the implementations. Instead of creating separate classes for every possible combination (like “EspressoWithMilk” or “LatteWithSugar“), the Bridge Pattern lets coffee delegate to add-ons through composition. This makes the system more flexible, that allows new coffee types or new add-ons to be added without changing existing code, and avoids the explosion of subclasses.

Abstraction

The Abtraction here is not same as in Abstract classes or Interfaces. It is a higher level of abstraction that separates the interface from the implementation.

We only see “what” we need to see, instead of “how” it is implemented. The Abstraction contains a reference to the Implementor.

Implementor

The Implementor defines the interface for implementation classes. This interface doesn’t have to be exactly match to Abstraction’s interface; in fact, the two interfaces can be different. Typically, the Implementor interface provides only primitive operations, and Abstraction defines higher-level operations based on those primitives.

We don’t care about “what” it does, we care about “how” it is done. The Implementor doesn’t contain any reference to the Abstraction.

Implementation of Bridge Design Pattern in C++

Let’s implement the Bridge Design Pattern in C++ using the coffee shop example mentioned earlier. We’ll create an abstraction for Coffee and an implementor for AddOns.

Steps to Implement Bridge Design Pattern

Following image shows the steps to implement Bridge Design Pattern.

C++ Code for Bridge Design Pattern

In this example, we have an abstract class AddOn that defines the interface for add-ons like Milk, Sugar, and Honey. The Coffee class is the abstraction that contains a reference to an AddOn. The concrete classes Espresso and Latte are refined abstractions that implement the serve() method.

#include <iostream>usingnamespace std;// Implementor: AddOnclassAddOn{public:virtualvoidadd()=0;};// Concrete AddOn: MilkclassMilk:public AddOn{public:voidadd()override{
         cout <<"with Milk";}};// Concrete AddOn: SugarclassSugar:public AddOn{public:voidadd()override{
         cout <<"with Sugar";}};// Concrete AddOn: HoneyclassHoney:public AddOn{public:voidadd()override{
         cout <<"with Honey";}};// Abstraction: CoffeeclassCoffee{protected:// Bridge
     AddOn* addon;public:Coffee(AddOn* a):addon(a){}virtualvoidserve()=0;};// Refined Abstraction: EspressoclassEspresso:public Coffee{public:Espresso(AddOn* a):Coffee(a){}voidserve()override{
         cout <<"Espresso ";
         addon->add();
         cout << endl;}};// Refined Abstraction: LatteclassLatte:public Coffee{public:Latte(AddOn* a):Coffee(a){}voidserve()override{
         cout <<"Latte ";
         addon->add();
         cout << endl;}};// Clientintmain(){
   AddOn* milk =newMilk();
   AddOn* sugar =newSugar();// Espresso with Milk
   Coffee* espressoMilk =newEspresso(milk);// Latte with Sugar
   Coffee* latteSugar =newLatte(sugar);

   espressoMilk->serve();
   latteSugar->serve();delete milk;delete sugar;delete espressoMilk;delete latteSugar;}

Following is the output of the above code −

Espresso with Milk
Latte with Sugar

In this implementation, we can easily add new types of coffee or new add-ons without modifying existing code. For example, we can create a new class Mocha that extends Coffee or a new class Caramel that extends AddOn, and the existing classes will remain unaffected.

When to Use Bridge Design Pattern

• Change how things work without changing what they do − Use Bridge to swap or update implementations anytime.
• Grow both sides easily − Add new features or new ways of doing things without breaking old code.
• Keep code clean and easy to change − Bridge keeps things simple and ready for easy updates.
• Handle lots of choices and combinations − Manage many types and options without confusion.
• Avoid too many classes − Prevent a mess of classes for every mix—use composition instead.

Real-world Software Use-cases of Bridge Design Pattern

Following is a diagram that shows some real-world software use-cases of Bridge Design Pattern.

Conclusion

In this chapter, we learned about the Bridge Design Pattern, which is a structural design pattern that separates an abstraction from its implementation. We discussed the components of the pattern, including Abstraction and Implementor, and saw how they work together and provide way to extend both independently and maintain flexibility(composition over inheritance). We also implemented the Bridge Design Pattern in C++ using a coffee shop example, demonstrating how to create abstractions for Coffee and implementors for AddOns. Finally, we explored when to use the Bridge Design Pattern and some real-world software use-cases.

Adapter is a part of Structural Design Patterns. Adapter pattern works like a bridge between two incompatible interfaces. It involves a single class which is responsible for joining the functionalities of interfaces that are independent and not compatible with each other. This pattern is also known as Wrapper.

Adapter works as a middleman of two things that do not go along together. For example, your laptop has a USB port and you have a SD card that you want to connect to your laptop. Here, USB and SD are two incompatible interfaces. To make them compatible, you need an adapter that can convert SD to USB. So, in the market you will find SD to USB adapter. This adapter will have SD port on one side and USB port on another side. You can connect your SD card to the adapter and then connect the adapter to your laptop’s USB port. Now, you can access your SD card data through your laptop.

The Adapter pattern is used when you want to use some existing code, but its interface does not match the one you need. In such cases, you create an adapter class that implements the interface you want and translates calls to the existing code.

In the above image, we have a Phone which does not have headphone jack. So, we cannot connect our headphones directly to the Phone. To solve this problem, we use an Adapter which has a lightning connector on one side and a headphone jack on another side. We can connect the adapter to the Phone and then connect our headphones to the adapter. This way, we can use our headphones with the Phone. This is an example of the Adapter pattern in real life.

Types of Adapter Pattern

There are two types of Adapter pattern −

• Class Adapter Pattern − In this, we use multiple inheritance to adapt one interface to another.
• Object Adapter Pattern − We use composition to adapt one interface to another.

Let’s understand in detail how these two types of adapter patterns work.

Class Adapter Pattern in C++

We use Class Adapter Pattern when we want to adopt one interface to another using multiple inheritance. In this pattern, the adapter class inherits from both the target interface and the adaptee class. This way, the adapter can override methods from the target interface and use methods from the adaptee class to provide the functionality we want.

Steps to implement Class Adapter Pattern are as follows −

Example of Class Adapter Pattern in C++

In this example, a modern music player wants us to play MP3 files, but we only have an old cassette player. Using the Class Adapter Pattern, we adapt the old cassette player so it can be used as an MP3 player.

#include <iostream>usingnamespace std;// Target interfaceclassIMediaPlayer{public:virtualvoidplayMP3(string filename)=0;};// Adaptee classclassOldCassettePlayer{public:voidplayCassette(string tape){
         cout <<"Playing cassette tape: "<< tape << endl;}};// Adapter classclassCassetteToMP3Adapter:public IMediaPlayer, private OldCassettePlayer{public:voidplayMP3(string filename)override{// Convert MP3 filename to cassette tape format
         string tape = filename +".cassette";playCassette(tape);// Use the adaptee's method}};// Client codeintmain(){
   IMediaPlayer* player =newCassetteToMP3Adapter();
   player->playMP3("MyFavoriteSong");delete player;return0;}

Following is the output of the above code −

Playing cassette tape: MyFavoriteSong.cassette

In this example, the IMediaPlayer interface is the target interface that expects an MP3 player. The OldCassettePlayer class is the adaptee that can only play cassette tapes. The CassetteToMP3Adapter class inherits from both the target interface and the adaptee class, allowing it to adapt the cassette player to work as an MP3 player.

Object Adapter Pattern in C++

We use Object Adapter Pattern when we want to adopt one interface to another using composition. In this pattern, the adapter class contains an instance of the adaptee class and implements the target interface. The adapter class translates calls from the target interface to the adaptee class.

Steps to implement Object Adapter Pattern are as follows:

Steps are almost same as Class Adapter Pattern except that in Object Adapter Pattern we use composition (has-a relationship) instead of inheritance (is-a relationship).

Example of Object Adapter Pattern in C++

Now, Let’s implement the same example of music player using Object Adapter Pattern.

#include <iostream>usingnamespace std;// Target interfaceclassIMediaPlayer{public:virtualvoidplayMP3(string filename)=0;};// Adaptee classclassOldCassettePlayer{public:voidplayCassette(string tape){
         cout <<"Playing cassette tape: "<< tape << endl;}};// Adapter classclassCassetteToMP3Adapter:public IMediaPlayer{private:
      OldCassettePlayer* cassettePlayer;// Compositionpublic:CassetteToMP3Adapter(OldCassettePlayer* player){this->cassettePlayer = player;}voidplayMP3(string filename)override{// Convert MP3 filename to cassette tape format
         string tape = filename +".cassette";
         cassettePlayer->playCassette(tape);// Use the adaptee's method}};// Client codeintmain(){
   OldCassettePlayer* oldPlayer =newOldCassettePlayer();
   IMediaPlayer* player =newCassetteToMP3Adapter(oldPlayer);
   player->playMP3("MyFavoriteSong");delete player;delete oldPlayer;return0;}

Following is the output of the above code −

Playing cassette tape: MyFavoriteSong.cassette

In this example, the IMediaPlayer interface is the target interface that expects an MP3 player. The OldCassettePlayer class is the adaptee that can only play cassette tapes. The CassetteToMP3Adapter class implements the target interface and contains an instance of the adaptee class, which allows it to adapt the cassette player to work as an MP3 player.

When to use Adapter Pattern?

You should consider using the Adapter pattern in the following scenarios −

• When you want to use an existing class, but its interface does not match the one you need.
• To create a reusable class that can work with different interfaces.
• While integrating third-party libraries or legacy code that have incompatible interfaces.
• Decoupling the client code from the implementation details of the adaptee class.
• When you want to provide a standard interface for a set of classes with different interfaces.

Real World Applications of Adapter Pattern

Some real-world applications in software development where the Adapter pattern is commonly used are shown in the below image −

Conclusion

This chapter was about the Adapter design pattern. It’s a structural pattern that helps in making incompatible things work together. We looked at both the Class Adapter and Object Adapter with C++ examples. The Adapter pattern is very useful when working with old code or third-party libraries that don’t match our interface. In short, it makes things work together that normally wouldn’t.