The Adapter pattern is useful when integrating third-party libraries because it lets you translate an external library's interface into the interface your application already expects, without modifying either the library or your existing code.
Key Points: • It isolates third-party API changes behind a single adapter class instead of scattering library calls throughout the codebase. • Your application code stays consistent, coding against its own interface rather than the library's specific API. • If the library is later swapped for another, only the adapter needs to change. • It avoids touching library source code, which is often impossible or undesirable for third-party dependencies. • It makes the third-party dependency easier to mock or stub in tests.
Example: If your application defines a PaymentProcessor interface but wants to use a third-party StripeClient with a different method signature, a StripeAdapter can implement PaymentProcessor and translate calls into the StripeClient API underneath.
Interview Tip: A concise interview answer is:
"Adapter is useful for third-party integration because it lets me translate an external library's interface into the interface my application already uses, without modifying the library or scattering library-specific calls throughout my codebase — if the library changes or gets replaced, only the adapter needs updating."