Review and Refactor

trigger OpportunityTrigger on Opportunity (before update, after update) {
    OpportunityTriggerHandler handler = new OpportunityTriggerHandler();
    if (Trigger.isBefore) {
        handler.beforeUpdate(Trigger.new, Trigger.oldMap);
    }
    if (Trigger.isAfter) {
        handler.afterUpdate(Trigger.new, Trigger.oldMap);
    }
}

Three pieces, each with one clear job: OpportunityTrigger (routes events), OpportunityTriggerHandler (detects what changed and by how much), AccountRollupService (applies the adjustment). This mirrors every project module's closing lesson — a system that works, then reviewed once more with fresh eyes.

• Bulk-safe? Yes — exactly one query and one DML statement in the rollup path, regardless of batch size (Module 25).
• Thin trigger? Yes — the trigger body only routes to handler methods (Module 24).
• Single Responsibility? Yes — three classes, three distinct jobs (Module 14).
• Validated? Yes — a Closed Won Opportunity can't save without a positive Amount (this module, Lesson 4).
• Verified? Yes, manually — formal automated tests are still ahead, in Module 31.

public class OpportunityTriggerHandler {
    private static final String CLOSED_WON = 'Closed Won';

    public void afterUpdate(List<Opportunity> newOpportunities, Map<Id, Opportunity> oldMap) {
        for (Opportunity opp : newOpportunities) {
            Opportunity oldOpp = oldMap.get(opp.Id);
            Boolean justWon = opp.StageName == CLOSED_WON && oldOpp.StageName != CLOSED_WON;
            // ...
        }
    }
}

The literal string 'Closed Won' appears in three separate places across this module's code so far — a classic candidate for Module 13's final keyword: one named constant, changed in exactly one place if the stage name ever needs to change, instead of hunting down every copy.