Enums (course slides)

Java.

enum WeekDay {
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY,
}

public boolean isWeekend(WeekDay weekDay) {
    return weekDay == WeekDay.SATURDAY || weekDay == WeekDay.SUNDAY;
}

Enums are a predefined list of specific values. Defining one creates a new data type, usable anywhere any other data type can be used.

Why enums? (the direction-finder story)

Starting point: a DirectionFinder.findDirection(int degrees) returns plain Strings ("north", "north-east", ...), and a main method branches on those strings with .equals(...) to print a message per direction.

Problem: when requirements change (say, only the 4 main directions are supported now, and the diagonal branches in findDirection are removed), the main method's else if (direction.equals("north-east")) branches still compile fine — they're just dead code now, silently never reached. Nothing forces you to notice or clean them up.

Fix: replace the String return type with an enum Direction { NORTH, EAST, SOUTH, WEST, NORTH_EAST, SOUTH_EAST, SOUTH_WEST, NORTH_WEST }, and compare with == against the enum constants instead of .equals() against string literals.

public enum Direction {
    NORTH, EAST, SOUTH, WEST,
    NORTH_EAST, SOUTH_EAST, SOUTH_WEST, NORTH_WEST,
}

public class DirectionFinder {
    public Direction findDirection(int degrees) {
        if (degrees == 0) return Direction.NORTH;
        else if (degrees == 90) return Direction.EAST;
        else if (degrees == 180) return Direction.SOUTH;
        else if (degrees == 270) return Direction.WEST;
        else if (degrees > 0 && degrees < 90) return Direction.NORTH_EAST;
        else if (degrees > 90 && degrees < 180) return Direction.SOUTH_EAST;
        else if (degrees > 180 && degrees < 270) return Direction.SOUTH_WEST;
        else return Direction.NORTH_WEST;
    }
}

Now, if the diagonal enum constants (NORTH_EAST, etc.) are later removed from the enum declaration because they're no longer needed, every place in the code still referencing Direction.NORTH_EAST fails to compile. The dead-code problem from before becomes a compiler error instead of a silent bug — exactly what you want: the compiler forces you to find and clean up every leftover reference.

Adding fields to an enum

public enum Direction {
    NORTH("north"), EAST("east"), SOUTH("south"), WEST("west"),
    NORTH_EAST("north east"), SOUTH_EAST("south east"),
    SOUTH_WEST("south west"), NORTH_WEST("north west");

    private String name;

    Direction(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return name;
    }
}

An enum constant can carry its own data (via a constructor, same as a regular class) — here, a human-readable display name, and a toString() override that returns it.

Recap

• Enums express a fixed, predetermined set of values/choices.
• Alternative would be plain Strings or numbers — but those allow any value, not just the intended few.
• Enums give type safety: the compiler rejects a reference to an enum value that doesn't exist, catching mistakes (and stale code, per the example above) at compile time instead of at runtime or never.
• More at: https://www.baeldung.com/java-enum-values

switch on enums

public enum TShirtSize { S, M, L }

TShirtSize size = getTShirtSize();
switch (size) {
    case S:
        System.out.println("Please follow me to this area of the store.");
        break;
    case M:
        System.out.println("They are right here");
        break;
    case L:
        System.out.println("You can find those over there");
        break;
    default:
        System.out.println("Sorry, but we don't have this size.");
        break;
}

switch works the same way on enum constants as on Strings/ints (case VALUE: per branch, break to avoid fallthrough, default for anything unmatched) — but combined with an enum, it gets the same type-safety benefit as == comparisons above.