Build a Bulk-Safe Trigger

trigger LeaveRequestTrigger on Leave_Request__c (before insert) {
    new LeaveRequestTriggerHandler().beforeInsert(Trigger.new);
}

Exactly Module 24's thin-trigger pattern — before insert, since overlap validation must block the save (Module 26's addError() lesson), which only works in a before context.

public void beforeInsert(List<Leave_Request__c> newRequests) {
    Set<String> employeeNames = new Set<String>();
    for (Leave_Request__c req : newRequests) {
        employeeNames.add(req.Employee_Name__c);
    }

    List<Leave_Request__c> existingRequests = [
        SELECT Id, Employee_Name__c, Start_Date__c, End_Date__c
        FROM Leave_Request__c
        WHERE Employee_Name__c IN :employeeNames AND Status__c != 'Rejected'
    ];
    // ... validation logic uses existingRequests (next lessons) ...
}

This is Module 16's Set deduplication (Module 25's bulkification instinct) combined into one upfront step: collect every affected employee's name once, then query all of their existing (non-rejected) requests in a single statement — before any per-record comparison starts.

// WRONG — a query per new request, exactly the anti-pattern from Module 25
for (Leave_Request__c req : newRequests) {
    List<Leave_Request__c> existing = [SELECT Id FROM Leave_Request__c WHERE Employee_Name__c = :req.Employee_Name__c];
    // ...
}

Querying inside the per-record loop would be the SOQL-in-a-loop problem from Module 25, at exactly the scale this feature is most likely to face — a bulk data load inserting hundreds of leave requests at once. Fetching everything needed before the loop begins is what keeps the actual comparison loop (next lesson) free of any database operation at all.