Dependency Inversion: Decoupling Your Apex Architecture

apex solid design-patterns

Stop hard-coding your logic and start injecting flexibility into your Salesforce org.

Dependency Inversion: Wiring Your Logic for Flexibility

The Dependency Inversion Principle (DIP) states two key things:

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend on details. Details should depend on abstractions.

In simpler terms: Don't hard-code your dependencies. Instead of a class "owning" its helper classes, it should "ask" for them via an interface. This is the secret to writing Apex that is truly unit-testable without relying on the database.

The "Hard-Coded" Mess (The Wrong Way)

Imagine a service that processes payouts. It is hard-coded to use a specific Stripe integration.

public class PayoutService {
    // High-level module depends directly on a low-level implementation
    private StripeLogger logger = new StripeLogger(); 
 
    public void sendMoney(Decimal amount) {
        // Business logic...
        logger.log('Processing: ' + amount);
    }
}

Why this is a problem:

  • Impossible to Unit Test: You can't test PayoutService without also involving StripeLogger.
  • Rigid: If you want to switch to PayPal or just log to a Custom Object instead of an external API, you have to rewrite the PayoutService.

Dependency Injection

We "invert" the relationship by introducing an interface. The PayoutService no longer knows how logging happens; it only knows that it can log.

1. The Abstraction

public interface ILogger {
    void log(String message);
}

2. The Flexible Implementation

public class PayoutService {
    private ILogger logger;
 
    // We "inject" the dependency via the constructor
    public PayoutService(ILogger logger) {
        this.logger = logger;
    }
 
    public void sendMoney(Decimal amount) {
        logger.log('Processing: ' + amount);
    }
}

Why DIP is a Game Changer for Salesforce

1. Lightning-Fast Unit Tests

With DIP, you can create a "Mock" logger for your tests. This allows you to test your business logic without actually inserting records or making callouts, which significantly speeds up your deployment times.

// In your test class
public class MockLogger implements ILogger {
    public void log(String message) { /* Do nothing, just for testing */ }
}
 
@IsTest
static void testPayout() {
    PayoutService service = new PayoutService(new MockLogger());
    service.sendMoney(100);
    // Assert business logic here without DML/Callout overhead!
}

2. Swapping Logic at Runtime

By combining DIP with Custom Metadata, you can decide which implementation to use without a code change. You can have a DebugLogger for Sandboxes and a SplunkLogger for Production, toggled by a simple metadata record.

Summary

The Dependency Inversion Principle is the "glue" that holds a professional Salesforce architecture together. It moves us away from brittle, monolithic scripts and toward a system of interchangeable parts.

By depending on abstractions, you make your code:

  • Testable: Isolate logic from side effects.
  • Maintainable: Change implementations without touching the consumer.
  • Scalable: Add new features by adding new classes, not by editing old ones.