Monostate Pattern: Shared Behavior Without a Single Instance

Monostate Pattern

Monostate — sometimes called the "Borg" pattern, after a Python idiom popularized by Alex Martelli — achieves the same practical outcome as Singleton (all callers observe and mutate the same shared state) through the opposite mechanism: instead of restricting how many objects exist, it lets you construct as many objects as you like, and simply makes their state shared via static fields. Every instance is behaviorally identical because they're all fronting the same underlying data.

1. Intent

Monostate answers a narrower question than Singleton: not "how do I guarantee only one object exists," but "how do I guarantee every object behaves identically, without callers having to know they're dealing with something special?" It moves the sharing from the instance level (Singleton: one object, referenced globally) to the state level (Monostate: many objects, one underlying data store).

This distinction matters in practice because callers of a Monostate class write completely ordinary object-oriented code — new Config(), pass it around, store it as a field — and get shared-state semantics for free, with no getInstance() call anywhere in the codebase.

2. The Naive Approach and Why Monostate Exists

Suppose a PrinterSettings class needs one shared paper size and orientation across the whole application, but the class is used throughout a large legacy codebase via ordinary new PrinterSettings() calls scattered across dozens of files — refactoring every call site to PrinterSettings.getInstance() would be a large, risky change.

// VIOLATION: each PrinterSettings instance has its OWN state —
// setting the paper size in one place doesn't affect any other instance.
class PrinterSettings {
    private String paperSize = "A4";
    private String orientation = "PORTRAIT";
 
    void setPaperSize(String size) { this.paperSize = size; }
    String getPaperSize() { return paperSize; }
}
 
// main() somewhere:
PrinterSettings userPrefs = new PrinterSettings();
userPrefs.setPaperSize("LETTER");
 
// ... deep in another module, constructed independently:
PrinterSettings printJob = new PrinterSettings();
System.out.println(printJob.getPaperSize()); // "A4" — the LETTER change is invisible here!

Converting this to Singleton would require rewriting every new PrinterSettings() call site into PrinterSettings.getInstance() — a large mechanical change across the codebase, and one that changes the type's public API shape (adds a static factory method, typically also requires making the constructor private, which breaks any code doing new PrinterSettings() directly). Monostate fixes the sharing without touching any call site.

3. Structure

Note what's absent compared to Singleton's structure: no private constructor, no getInstance(), no instance-count enforcement at all. The only change from an ordinary class is that instance fields become static fields, and the accessor/mutator methods remain ordinary instance methods that happen to read/write shared static storage.

4. Java Implementation

class PrinterSettings {
    // static — this is the ONLY change from a normal class: state lives at
    // the class level, not the instance level.
    private static String paperSize = "A4";
    private static String orientation = "PORTRAIT";
 
    // Constructor is public and completely ordinary — callers don't need
    // to know anything special is going on.
    public PrinterSettings() { }
 
    public void setPaperSize(String size) { paperSize = size; }
    public String getPaperSize() { return paperSize; }
 
    public void setOrientation(String orientation) {
        PrinterSettings.orientation = orientation;
    }
    public String getOrientation() { return orientation; }
}

// FIXED: any number of instances, all observing the same shared state
PrinterSettings userPrefs = new PrinterSettings();
userPrefs.setPaperSize("LETTER");
 
PrinterSettings printJob = new PrinterSettings(); // a genuinely different object
System.out.println(printJob.getPaperSize()); // "LETTER" — shared state, as intended
 
System.out.println(userPrefs == printJob); // false — they are NOT the same object,
                                            // unlike Singleton, where this would be true

Thread Safety Still Applies

Monostate doesn't sidestep concurrency concerns — it has exactly the same shared-mutable-state hazards as any other static field, so the same fixes apply:

class ThreadSafeSettings {
    private static volatile String paperSize = "A4";
 
    public synchronized void setPaperSize(String size) { // guard the write
        paperSize = size;
    }
    public String getPaperSize() { return paperSize; } // volatile read is safe unguarded
}

5. Monostate's Advantage: Inheritance and Polymorphism

Because Monostate uses ordinary instantiation, it composes cleanly with subclassing — something Singleton actively resists:

class PrinterSettings {
    protected static String paperSize = "A4";
    public void setPaperSize(String size) { paperSize = size; }
    public String getPaperSize() { return paperSize; }
}
 
// A subclass adds behavior while transparently sharing the same static state —
// this is awkward-to-impossible with a classic Singleton, since Singleton's
// "one instance" guarantee is usually tied to a specific concrete class.
class EcoPrinterSettings extends PrinterSettings {
    @Override
    public void setPaperSize(String size) {
        System.out.println("Eco mode: defaulting to recycled stock for " + size);
        super.setPaperSize(size);
    }
}
 
PrinterSettings normal = new PrinterSettings();
EcoPrinterSettings eco = new EcoPrinterSettings();
eco.setPaperSize("LETTER");
System.out.println(normal.getPaperSize()); // "LETTER" — shared even across subclass instances

Every PrinterSettings and EcoPrinterSettings instance — regardless of how many are created, in how many places — reads and writes the same static state, and each can still be used fully polymorphically (passed as a PrinterSettings reference, overridden methods, etc.).

6. Common Implementation Pitfalls

Monostate's simplicity hides a couple of sharp edges that are easy to introduce by accident, especially when a class grows over time and new fields are added by someone unfamiliar with the class's shared-state contract.

Pitfall: The "Partial Monostate" Bug

// VIOLATION: a new field was added WITHOUT the static keyword, because the
// author didn't realize (or forgot) that every field in this class must be
// shared, not just the original ones.
class PrinterSettings {
    private static String paperSize = "A4";   // shared, as intended
    private String orientation = "PORTRAIT";  // NOT static — silently instance-scoped!
 
    public void setPaperSize(String size) { paperSize = size; }
    public String getPaperSize() { return paperSize; }
 
    public void setOrientation(String o) { this.orientation = o; } // only affects THIS instance
    public String getOrientation() { return orientation; }
}
 
PrinterSettings a = new PrinterSettings();
PrinterSettings b = new PrinterSettings();
a.setOrientation("LANDSCAPE");
System.out.println(b.getOrientation()); // "PORTRAIT" — inconsistent with paperSize's sharing!

This compiles cleanly and produces no warning — orientation silently becomes ordinary per-instance state while paperSize stays shared, and every caller of the class now has to remember which fields are "really" shared and which aren't. There's no compiler enforcement of "every field in a Monostate class must be static"; it's a hand-maintained convention.

Pitfall: Assuming Constructor Logic Runs Once

// VIOLATION: initialization logic in the constructor re-runs on EVERY
// instantiation, not once — a common misconception carried over from Singleton.
class PrinterSettings {
    private static String paperSize;
 
    public PrinterSettings() {
        paperSize = loadDefaultFromConfigFile(); // runs on every `new`, not just the first!
    }
}
 
// Every `new PrinterSettings()` anywhere in the app re-reads the config file
// and resets paperSize back to the default — silently discarding any
// customization a caller made via setPaperSize() earlier.

Unlike Singleton (where the constructor runs exactly once, ever), Monostate's constructor runs on every instantiation — because there's nothing restricting instantiation at all. If the constructor has side effects intended to run only once (loading defaults, registering something), a guard is required:

// FIXED: explicit guard against re-running one-time initialization logic
class PrinterSettings {
    private static String paperSize;
    private static boolean initialized = false;
 
    public PrinterSettings() {
        if (!initialized) {
            paperSize = loadDefaultFromConfigFile();
            initialized = true;
        }
    }
}

7. Monostate vs. a Static Utility Class

A natural question once you've seen Monostate is: "why not just make everything static methods on a utility class and skip instances entirely?" The two look similar but solve different problems.

// Static utility class — no instances at all, no polymorphism, no interfaces
final class PrinterSettingsUtil {
    private PrinterSettingsUtil() { } // prevent instantiation entirely
 
    private static String paperSize = "A4";
 
    public static void setPaperSize(String size) { paperSize = size; }
    public static String getPaperSize() { return paperSize; }
}
 
// Usage — no object at all, ever:
PrinterSettingsUtil.setPaperSize("LETTER");

The critical difference is that a static utility class cannot implement an interface's instance methods, cannot be passed as a polymorphic reference, and cannot be subclassed to specialize behavior — static methods aren't part of any virtual dispatch table. Monostate keeps ordinary instance methods (so it participates in polymorphism, can implement interfaces, and can be subclassed as shown in Section 5); a static utility class is a flatter, more limited tool.

// Monostate CAN do this — a static utility class cannot:
interface Settings {
    void setPaperSize(String size);
    String getPaperSize();
}
 
class PrinterSettings implements Settings { // implements an interface — instances required
    private static String paperSize = "A4";
    public void setPaperSize(String size) { paperSize = size; }
    public String getPaperSize() { return paperSize; }
}
 
// Now PrinterSettings can be injected anywhere a Settings is expected,
// participate in dependency injection containers, be mocked via a subclass, etc.
// — none of which a static utility class permits.

8. Testing Monostate Classes

Shared static state creates exactly the same test-pollution risk in Monostate as it does in Singleton or any other static field — tests that mutate the shared state can leak into other tests unless carefully isolated:

class PrinterSettingsTest {
    @Test
    void testLetterSize() {
        PrinterSettings settings = new PrinterSettings();
        settings.setPaperSize("LETTER");
        assertEquals("LETTER", settings.getPaperSize()); // passes in isolation
    }
 
    @Test
    void testDefaultSize() {
        PrinterSettings settings = new PrinterSettings(); // a BRAND NEW instance...
        assertEquals("A4", settings.getPaperSize());
        // ...but FAILS if testLetterSize() ran first in the same JVM, because
        // the static field was never reset — "new" doesn't mean "fresh state."
    }
}

This is the same class of flakiness problem covered for Singleton in the Singleton Pattern guide — the fix is the same shape too: an explicit reset hook, run in @BeforeEach/@AfterEach, or isolating each test in its own process/classloader:

class PrinterSettings {
    private static String paperSize = "A4";
    // ...
 
    // Package-private or test-only reset hook — an explicit admission that
    // static state needs explicit lifecycle management in tests.
    static void resetForTesting() { paperSize = "A4"; }
}
 
class PrinterSettingsTest {
    @BeforeEach
    void resetSharedState() {
        PrinterSettings.resetForTesting();
    }
    // ... tests are now order-independent
}

Monostate Inside a DI Container

A subtler pitfall shows up when Monostate classes are registered as beans in a dependency-injection container (Spring, etc.):

@Component
class PrinterSettings {
    private static String paperSize = "A4"; // still static — still shared across ALL instances
 
    public void setPaperSize(String size) { paperSize = size; }
    public String getPaperSize() { return paperSize; }
}

Spring's default bean scope already makes PrinterSettings a de facto singleton bean — exactly one instance is created and injected everywhere. Adding static fields on top of that doesn't add sharing (the container already guarantees one instance); it just reintroduces the same hidden-static-state risk described in this guide's pitfalls, now hidden underneath a framework that was already providing the sharing safely via ordinary instance fields.

9. Monostate vs. Singleton

This is the comparison interviewers most often ask for directly, since the two patterns are frequently confused:

10. When to Use vs. When It's Overkill

11. Real-World / Production Examples

• Legacy codebase migrations. Introducing process-wide shared configuration into a large, procedural-turned-OO codebase with hundreds of scattered new SomeConfig() call sites — Monostate is frequently the only migration path that doesn't require touching every call site in a single risky change.
• Python's Borg idiom (the pattern's origin, via shared __dict__ rather than static fields — Java's static fields are the direct structural equivalent): widely used in scripting and plugin systems where instantiation is driven by a host framework, not by your own code, so you can't force callers through a factory method.
• Test fixture builders. A TestContext instantiated freely in every test method but sharing ID/sequence generators across a run via static counters, so unique identifiers stay unique across the whole suite without threading a shared context object through every helper method by hand.
• Embedded and plugin architectures. Frameworks that instantiate your class themselves via reflection or a service-provider interface (e.g. ServiceLoader) won't call a static getInstance() factory method — they call new directly. If shared state is required under that constraint, Monostate is frequently the only pattern that fits, since Singleton's private-constructor requirement is incompatible with framework-driven instantiation.
• Feature-flag / experiment-state shims. A thin FeatureFlags class instantiated per-call-site for readability (new FeatureFlags().isEnabled("x") reads better inline than a long static import) while the underlying flag values are fetched once and cached in shared static state.
• Counter and metrics accumulator objects handed out to many unrelated call sites that each construct their own local reference but need to contribute to one running total — Monostate avoids threading a shared accumulator object through every method signature.

Interview Questions

• What is the fundamental mechanism difference between Singleton and Monostate — one sentence each?
• Why would a team choose Monostate over Singleton when retrofitting shared state onto an existing codebase?
• Why does Monostate support inheritance and polymorphism more naturally than Singleton?
• What's the biggest risk of Monostate's "looks like an ordinary class" property, and how would you mitigate it in code review?
• Is Monostate thread-safe by default? What would you add to make it safe under concurrent access?
• What is the "partial Monostate" bug, and why does the compiler not catch it for you?
• Why does constructor logic in a Monostate class need an explicit "run once" guard, unlike Singleton's constructor?
• If two PrinterSettings instances are compared with ==, what's the result under Monostate, and why does that surprise developers coming from Singleton?
• Why can't a static utility class (all-static methods, no instances) implement an interface the way a Monostate class can? Why does that matter?
• How would you write a JUnit test suite for a Monostate class so that tests don't leak state into each other?
• In what scenario would neither Singleton nor Monostate be appropriate, and dependency injection with per-request scope should be used instead?