Adapter and Facade Patterns

# CHAPTER 11

Adapter and Facade Patterns #

1. Introduction #

2. Learning Objectives #

• Define the intent of Structural Design Patterns.

• Understand how the Adapter pattern acts as a real-world translator.

• Implement an Adapter to safely integrate a third-party API.

• Understand the Facade pattern's role in simplifying complex systems.

• Distinguish between an Adapter (changing interfaces) and a Facade (simplifying interfaces).

3. The Adapter Pattern #

• The Problem: Your analytics app expects data in XML format. The new stock market API you just purchased only returns JSON. They cannot communicate.

• The Solution: You create a JsonToXmlAdapter class. Your app talks to the Adapter using standard XML method calls. The Adapter silently translates that request into JSON, fetches the data from the API, translates it back to XML, and returns it. Your app never knows JSON was involved.

4. The Facade Pattern #

• The Problem: To process a video upload, your code has to manually instantiate the FFmpegEncoder, calculate the BitrateManager, open the AwsS3Connection, and trigger the NotificationService. This is 50 lines of complex, error-prone code scattered throughout your app.

• The Solution: You create a VideoUploaderFacade class with a single method: uploadVideo(file). The Facade hides the 50 lines of terrifying subsystem logic behind one simple, easy-to-use doorway.

5. Adapter vs. Facade (The Difference) #

• Adapter: Makes an existing interface usable. It takes a *complex/incompatible* interface and changes it into the *specific* interface you need. (Translating).

• Facade: Makes a complex subsystem easy to use. It takes *dozens of complex* classes and provides a *single simplified* interface to control them all. (Simplifying).

6. UML Diagrams #

[ Client ] ---> [ <<Interface>> Target ]
                       ^
                       | (Implements)
                 [ Adapter ]
                       | (Contains & Translates)
                       v
                 [ Incompatible Service ]

*Facade Structure*

[ Client ] ---> [ Facade ]
                   |---> [ Subsystem A ]
                   |---> [ Subsystem B ]
                   |---> [ Subsystem C ]

7. Code Example: Adapter (PHP) #

<?php
// --- 1. Our Application's Standard Interface (The American Plug) ---
interface PaymentGateway {
    public function sendPayment($amount);
}

// --- 2. The Incompatible Third-Party API (The European Socket) ---
class StripeAPI {
    // We cannot change this code. It's a vendor library.
    public function makeStripeCharge($dollars, $cents, $currency) {
        echo "Stripe: Charged $currency $dollars.$cents\n";
    }
}

// --- 3. The Adapter ---
class StripeAdapter implements PaymentGateway {
    private $stripe;

    public function __construct(StripeAPI $stripe) {
        $this->stripe = $stripe; // Wrap the incompatible object
    }

    // Translate our standard interface into the complex vendor logic
    public function sendPayment($amount) {
        $dollars = floor($amount);
        $cents = ($amount - $dollars) * 100;
        
        $this->stripe->makeStripeCharge($dollars, $cents, "USD");
    }
}

// --- 4. Client Code ---
// The client only knows about our standard interface.
function processCart(PaymentGateway $gateway, $total) {
    $gateway->sendPayment($total);
}

// We plug the incompatible API into the Adapter, and give the Adapter to the App.
$vendorAPI = new StripeAPI();
$adapter = new StripeAdapter($vendorAPI);

processCart($adapter, 99.50); // Output: Stripe: Charged USD 99.50
?>

8. Best Practices #

• Anti-Corruption Layer (ACL): In enterprise microservices (Domain-Driven Design), the Adapter pattern is heavily used to create an Anti-Corruption Layer. By forcing all external API communication through Adapters, you prevent the changing, messy logic of third-party vendors from "corrupting" the clean, internal logic of your core application.

9. Common Mistakes #

• The God Facade: If you put *every single feature* of your application behind one massive SystemFacade class, it stops being a helpful doorway and becomes a terrifying God Class that violates the Single Responsibility Principle. Facades should be scoped to specific subsystems (e.g., BillingFacade, SearchFacade).

10. Mini Project: Build an Image Conversion Facade #

1. 1. The Subsystem: Imagine you have three complex classes: FileReader, JpegToPngConverter, and FileWriter.

1. 2. The Facade: Create a simple ImageConverterFacade class.

1. 3. The Method: Give it one method: convert($filename, $format).

1. 4. The Execution: The Facade takes the simple command, opens the FileReader, passes the data to the Converter, and uses the FileWriter to save it. The client code achieves this in exactly one line of code.

11. Practice Exercises #

1. 1. Define the primary intent of the Adapter pattern. Explain the "Travel Adapter" analogy.

1. 2. Compare the structural intent of the Adapter pattern against the Facade pattern. When would an architect choose to use a Facade?

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain how the Adapter pattern enforces the SOLID Dependency Inversion Principle when dealing with unstable third-party APIs (like Stripe or Twilio).

• Q: Walk me through the concept of an "Anti-Corruption Layer." How does wrapping external systems in Adapters protect your core business logic from breaking changes implemented by vendors?

• Q: A junior developer creates a massive class containing thousands of lines of code that interacts with every subsystem in the application, and calls it an "ApplicationFacade." Explain why this violates SOLID principles and how you would refactor it.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #