SOLID Principles in Apex

// VIOLATES SRP: one class doing validation, calculation, AND email
public class OrderProcessor {
    public Boolean isValid(Order__c order) { ... }
    public Decimal calculateTax(Order__c order) { ... }
    public void sendConfirmation(Order__c order) { ... }
}

A class should have exactly one reason to change. OrderProcessor above would need editing if the validation rules change, if the tax rate changes, or if the email template changes — three unrelated reasons tangled into one class. Splitting it into OrderValidator, TaxCalculator, and OrderNotifier gives each class a single, focused responsibility.

public interface DiscountStrategy {
    Decimal apply(Decimal price);
}

public class SeasonalDiscount implements DiscountStrategy {
    public Decimal apply(Decimal price) { return price * 0.9; }
}

public class LoyaltyDiscount implements DiscountStrategy {
    public Decimal apply(Decimal price) { return price * 0.85; }
}

A class should be open to extension but closed to modification — adding a new kind of discount means writing a new class that implements DiscountStrategy, never editing existing discount classes. This is Module 11's interfaces and polymorphism directly enabling a SOLID principle.

• Liskov Substitution — a subclass should be usable anywhere its parent is expected, without breaking anything. If SalariedManager extends Employee but somehow behaves incorrectly wherever a plain Employee was expected, that's a Liskov violation.
• Interface Segregation — prefer several small, focused interfaces over one giant one. A class shouldn't be forced to implement methods it doesn't actually need.
• Dependency Inversion — depend on an interface (like DiscountStrategy), not a specific concrete class — exactly what the Open/Closed example above already does, since OrderProcessor could hold a DiscountStrategy field without caring which specific implementation it is.