Dependency Injection in Apex

public with sharing class TransactionBalanceService {
    public static void applyDeltas(List<Transaction__c> transactions) {
        BankAccountSelector selector = new BankAccountSelector(); // hardcoded
        // ...uses selector to query and update balances
    }
}

Because TransactionBalanceService constructs its own BankAccountSelector internally, a test exercising this method has no way to substitute a fake selector — every test is forced to rely on BankAccountSelector's real SOQL query actually running against test data.

public with sharing class TransactionBalanceService {
    private BankAccountSelector selector;

    public TransactionBalanceService(BankAccountSelector selector) {
        this.selector = selector;
    }

    public TransactionBalanceService() {
        this(new BankAccountSelector()); // sensible real-world default
    }

    public void applyDeltas(List<Transaction__c> transactions) {
        // ...uses this.selector instead of constructing one internally
    }
}

The no-argument constructor still exists for normal production use (new TransactionBalanceService()), but a test can now call new TransactionBalanceService(fakeSelector) and pass in a test-only substitute — this is the entire idea of dependency injection, in nine lines of Apex.

For a class whose dependency is a simple selector, this benefit is modest — Module 42's tests already worked fine inserting real records. Dependency injection earns its keep more clearly when a dependency is expensive or hard to set up in a test at all (an external callout, Module 36, or a slow batch process, Module 38) — situations where substituting a fake becomes genuinely necessary rather than just convenient.