Custom Types in Collections: Wrapper Classes

List<String> productNames = new List<String>{'Widget', 'Gadget'};
List<Decimal> productPrices = new Decimal[]{49.99, 89.99};

Two separate lists, kept in sync by position only — fragile, since sorting or filtering one list without the other would silently misalign productNames[0] with the wrong price. Nothing enforces that these two lists stay related.

public class ProductSummary {
    public String name;
    public Decimal price;

    public ProductSummary(String name, Decimal price) {
        this.name = name;
        this.price = price;
    }
}

List<ProductSummary> products = new List<ProductSummary>{
    new ProductSummary('Widget', 49.99),
    new ProductSummary('Gadget', 89.99)
};

for (ProductSummary p : products) {
    System.debug(p.name + ': R' + p.price);
}

This is exactly Module 10's class-and-object pattern, now storing custom objects inside a List — each ProductSummary keeps its own name and price permanently together, with no risk of two separate lists drifting out of sync.

public class TicketSummary {
    public String subject;
    public String priority;
    public Integer daysOpen;

    public TicketSummary(String subject, String priority, Integer daysOpen) {
        this.subject = subject;
        this.priority = priority;
        this.daysOpen = daysOpen;
    }
}

List<TicketSummary> openTickets = new List<TicketSummary>{
    new TicketSummary('Login failure', 'High', 2),
    new TicketSummary('Slow report load', 'Medium', 5)
};

A dashboard displaying open support tickets needs several fields per ticket shown together — exactly the case where a List<sObject> (a real Salesforce record) or a custom wrapper class like TicketSummary (useful when the data doesn't map cleanly to one object) both outperform several parallel primitive lists.