Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A structural design pattern that wraps a class with an incompatible interface so it matches the interface your code expects, like a travel plug adapter for software.
In short
The adapter pattern, or adapter design pattern, is a structural pattern that converts the interface of an existing class into the interface your code expects, so two incompatible pieces can work together. The adapter wraps the old class and translates every call, in both directions.
In short
The adapter pattern, or adapter design pattern, is a structural pattern that converts the interface of an existing class into the interface your code expects, so two incompatible pieces can work together. The adapter wraps the old class and translates every call, in both directions.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Adapter Pattern across a run of lessons, not one page. These 4 alone are about 71 minutes of step-by-step reading, every one with a quiz.
Make incompatible interfaces work together, the universal translator of software architecture.
Standardize the output of your application, transform logs, metrics, and data into formats your infrastructure expects.
Simplify complex subsystems by providing a unified interface, the front desk of your software architecture.
Migrate from monolith to microservices incrementally, replacing pieces one at a time while the old system stays alive.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
Ive started this course by accident - LLM advised me this site. When I passed few free lessons, I had no doubt - this course should be bought. And I did it with special pleasent price and it was best decision of the month. Content is great, interesting to read and with a lot of practial cases (what makes it different from other souces and books) I hope to teach all the lessons, that will be my supergoal. Glad that I found this resource and speacial Thank You to Roni Das - Great Job!
You own this course
Continue with Adapter Patternpay once,
yours for life
An interface is the set of method names, parameters and return shapes that code uses to talk to an object. Two pieces of code can do the same job and still have different interfaces. Then they cannot be plugged together directly.
The Gang of Four book states the intent of Adapter like this: convert the interface of a class into another interface clients expect. Adapter lets classes work together that could not otherwise, because of incompatible interfaces.
The lesson compares it to a travel plug. A power adapter lets a US laptop use a European socket. It does not change the laptop or the electricity. It only changes the shape of the plug. A software adapter does the same for method calls.
Adapter is one of the structural patterns, the group about how objects are put together. See structural design patterns for the group and design patterns for the full catalogue.
Every adapter has the same three parts. The lesson names them in a small table.
The client, here the Checkout Service, only ever calls the Target. It does not know an adapter exists. It certainly does not know about Razorpay.
The lesson follows one payment through the adapter.
Drawn from the lesson Adapter Pattern.
Notice the two kinds of arrow. The dashed arrow says the adapter implements the interface. The solid arrow says the adapter calls the SDK. Checkout has no arrow to Razorpay at all, so the checkout code never imports a single Razorpay type.
There are two ways to build an adapter. The lesson uses the first one, and it is the common choice in modern code.
An object adapter holds the adaptee as a field. When a call arrives, it translates the arguments and delegates to that object at run time. This is composition: the adapter has an adaptee. It works with any language, and one adapter can wrap any object that has the adaptee's interface.
A class adapter inherits from the adaptee class instead. It implements the target interface and calls the inherited methods directly. This needs a language that lets a class inherit an implementation and also implement an interface. It ties the adapter to one concrete adaptee class at compile time.
If you are unsure, pick the object adapter. It keeps the vendor class at arm's length, which is the reason you wanted an adapter in the first place.
Without an adapter you have two bad choices. You can reshape your whole payment code around one vendor's API, and reshape it again when you change vendor. Or you can scatter small translations everywhere the vendor is used.
The lesson zooms out to layers. Your application code sits at the top and speaks only your types. The adapter layer translates to vendor types, with one adapter per vendor. The vendor SDKs handle the network details. The external APIs sit at the bottom.
This layering limits damage. A breaking change in an SDK touches one adapter file. A new vendor means one new adapter class, such as a Stripe adapter next to the Razorpay one. The application code, several layers away, does not change.
The lesson lists common places for adapters in microservices. One is a payment service that supports Stripe, Razorpay and PayPal behind one interface. Another is a service with a DatabaseAdapter for both DynamoDB and PostgreSQL. A third is an API gateway that normalises responses from many backends. Adapters also appear in an anti-corruption layer, which keeps another system's model out of yours. The anti-corruption layer lesson covers that case.
Four structural patterns all wrap another object, so they are easy to mix up. The lesson gives a quick test based on intent.
One more name clash. This page is the object-oriented Adapter. The Adapter Container pattern is a different idea: a container that runs next to your app and converts its logs and metrics into the format your monitoring expects. See the Adapter Container lesson.
The lesson gives three cases. If you control both interfaces, change one to match the other. If the translation is a single renamed field, write it inline. If you add adapters for every class just in case, that is over-engineering.
Use an adapter for third-party libraries and APIs, for legacy code that must fit a new system, and for any external service with several implementations. Each implementation gets its own adapter.
To step through the translation sequence and take the quiz, the Adapter Pattern lesson is the next step.
Payment providers behind one interface
The lesson's example: Stripe, Razorpay and PayPal each get an adapter that conforms to one unified payment interface, so checkout code stays the same.
Legacy user API
From the lesson's quiz: your app calls getUser(id), and the adapter calls the legacy fetchUserRecord({ userId: id, includeDeleted: false }).
An adapter changes the interface, so a class with the wrong method shapes can be used where another interface is expected. A decorator keeps exactly the same interface and adds behaviour, such as logging or retries, around the wrapped object. Decorators can also be stacked one on another, which plain adapters are not built for.
Adapter is structural: it makes two incompatible interfaces work together. Strategy is behavioral: it lets you swap between algorithms that already share the same interface. An adapter fixes a mismatch in shape, while a strategy choice changes what the code does.
Ports and adapters is another name for hexagonal architecture, described by Alistair Cockburn. A port is an interface the application defines for talking to the outside world. An adapter converts between that port and one real technology, such as a database driver, a user interface or a test harness. Each of those adapters is the Adapter pattern used at the edge of an application.
No. The adapter pattern is a class that wraps another class inside your code. The adapter container pattern is a separate container deployed next to a service that converts its output, such as logs and metrics, into a standard format for your infrastructure.
Design Patterns
Named, reusable solutions to problems that keep coming up in object-oriented code, such as creating objects, wrapping interfaces or reacting to events. The classic catalogue of 23 was published by the Gang of Four in 1994.
Facade Pattern
A structural design pattern that puts one simple interface in front of a complicated set of classes or services, so callers make one call instead of coordinating many.
Decorator Pattern
A structural design pattern that wraps an object in another object with the same interface to add behavior, such as logging, caching or retries, without changing the original class.
Structural Design Patterns
The family of design patterns about how classes and objects fit together: Adapter, Bridge, Composite, Decorator, Facade, Flyweight and Proxy. They change how pieces connect without changing what each piece does.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
This page explains the idea. The "Adapter Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Adapter Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.