All 15 Enums questions
More in Enums
How would you implement an enum that also implements an interface, and what's the benefit of having different enum constants provide different behavior through a shared interface contract? What are the ordinal() and name() methods on an enum constant, and why is relying on ordinal() for persistence or serialization considered dangerous? How do you correctly use an enum as a switch statement/expression's target, and what changed with the introduction of arrow-style switch expressions (Java 14+) regarding exhaustiveness and fall-through? What is the valueOf() method on an enum, and what happens when you pass a name that doesn't match any declared constant? How would you implement the Strategy pattern using an enum with constant-specific method bodies, and how does this compare to a traditional interface-based Strategy implementation? How does Java implement enums under the hood at the bytecode level (extending java.lang.Enum), and what makes them inherently thread-safe and serialization-safe as singletons? How would you use an EnumMap combined with a switch expression to implement a state machine, and what compile-time safety benefits does an exhaustive switch over an enum provide? How would you implement a custom enum that also functions as a lookup table (mapping an external code to a constant), such as parsing an HTTP status code string into an enum constant, handling unknown values gracefully? How would you implement a custom compareTo()-based ordering for an enum that differs from its natural declaration-order ordering, given Comparable's default implementation uses ordinal()? How would you handle adding behavior to an enum where the number of constants might grow very large or needs to be data-driven rather than hardcoded at compile time, and why might a class-based registry be more appropriate in that scenario?
Advertisement
Java › Enums

How would you use an enum to represent a fixed set of configuration keys combined with a shared lookup method, avoiding scattered String literal keys throughout a codebase?

Intermediate

Answer

Representing configuration keys as enum constants (rather than raw String literals scattered throughout the codebase) provides compile-time safety against typos (a misspelled String key silently returns null/default at runtime, while a misspelled enum reference simply fails to compile), IDE autocomplete support for discovering all valid keys, and a natural single place to attach metadata (default value, expected type, description) to each key via enum fields.
public enum ConfigKey {
    MAX_CONNECTIONS("max.connections", "100"),
    TIMEOUT_MS("timeout.ms", "5000");

    private final String propertyName;
    private final String defaultValue;
    ConfigKey(String propertyName, String defaultValue) {
        this.propertyName = propertyName; this.defaultValue = defaultValue;
    }
    public String propertyName() { return propertyName; }
    public String defaultValue() { return defaultValue; }
}

String timeout = System.getProperty(ConfigKey.TIMEOUT_MS.propertyName(), ConfigKey.TIMEOUT_MS.defaultValue());
Real-world example A large application replaces dozens of scattered raw String configuration key literals (prone to typos) with a centralized ConfigKey enum, catching an entire class of configuration-key typo bugs at compile time that previously would have silently fallen back to default values at runtime without any warning.

Common follow-ups: How would you extend this pattern to also validate or parse the configuration value's expected type (int, boolean, etc.) per key?;What's the trade-off of this enum-based approach versus a more dynamic, externally-configurable key system?

Configuration & Options Pattern;Java Fundamentals: Syntax Data Types & Operators
All 15 Enums questions