Design

Principles

• Integrate rather then reimplement
• Fail-fast
• Open-Closed
• Convension over configuration

Composite settings

One might ask: " Why is there no @Settings annotation"?

public class ApplicationSettings {
    @Setting
    private String setting1;
    @Setting
    private String setting2;
    ...
}

This approach is discouraged because:

• There is no way to atomically apply such settings;
• If ApplicationSettings hold unrelated settings, such class tend to evolve into "God object";
• In case of composite settings, such as, say, CacheSettings - you might want to use the same class for multiple objects (with different settings key).