Singleton Pattern

In simple words#

Learning objectives#

• Implement a Singleton in JavaScript and C#
• Understand why the constructor must be protected
• Use module and DI singletons instead of hand-made ones
• Know the testing and threading pitfalls

Explanation#

A Singleton hides its constructor and exposes a static access point (AppConfig.instance). The first call creates the object; later calls return the same one.

In C#, the simplest thread-safe version uses Lazy<T>, which creates the instance once even if many threads ask at the same moment.

In JavaScript, a module is already a singleton: every import of a module gets the same exported object. That is the most common JavaScript “singleton”.

In ASP.NET Core, prefer builder.Services.AddSingleton<ICache, MemoryCache>(): the container guarantees one instance, and tests can still replace it.

Singletons are global state in disguise. They make tests depend on each other and hide dependencies. Use them for truly shared, mostly read-only things.

Syntax#

1public sealed class AppConfig
2{
3    private static readonly Lazy<AppConfig> _instance = new(() => new AppConfig());
4    public static AppConfig Instance => _instance.Value;
5

6    private AppConfig() { }          // nobody else can call new
7

8    public string Theme { get; set; } = "light";
9}
10

11// Preferred in ASP.NET Core:
12builder.Services.AddSingleton<IAppConfig, AppConfig>();

Code example: One configuration for the whole app#

1class AppConfig {
2  static #instance = null;
3  #settings = new Map();
4

5  constructor() {
6    if (AppConfig.#instance) throw new Error('Use AppConfig.instance');
7  }
8

9  static get instance() {
10    if (!AppConfig.#instance) AppConfig.#instance = new AppConfig();
11    return AppConfig.#instance;
12  }
13

14  set(key, value) { this.#settings.set(key, value); }
15  get(key) { return this.#settings.get(key); }
16}
17

18const a = AppConfig.instance;
19a.set('theme', 'dark');
20

21const b = AppConfig.instance;        // somewhere else in the app
22console.log(a === b);
23console.log(b.get('theme'));
24

25try { new AppConfig(); } catch (e) { console.log(e.message); }
26

27// The everyday JavaScript singleton: a module-level object
28const idGenerator = (() => {
29  let last = 0;
30  return { next: () => ++last };
31})();
32console.log(idGenerator.next(), idGenerator.next());

true
dark
Use AppConfig.instance
1 2

Step-by-step explanation#

1. static #instance holds the single object; it starts as null.
2. The instance getter creates the object on first use (lazy creation) and returns the same one afterwards.
3. a and b are the same object, so a setting saved through a is visible through b.
4. Calling new directly is blocked once the instance exists.
5. idGenerator shows the simpler module-style singleton: one closure, shared state.

Real-world use case#

Common mistakes#

Best practices#

• Prefer DI singletons over hand-written ones
• Keep singleton state read-only or thread-safe
• Use Lazy<T> for hand-written C# singletons
• Never store per-user data in a singleton

Remember this#

Practice exercise#

1class Logger {
2  static #instance;
3  messages = [];
4  static getInstance() { return (Logger.#instance ??= new Logger()); }
5  log(msg) { this.messages.push(msg); }
6}
7Logger.getInstance().log('from checkout');
8Logger.getInstance().log('from login');
9console.log(Logger.getInstance().messages);                   // [ 'from checkout', 'from login' ]
10console.log(Logger.getInstance() === Logger.getInstance());   // true

Mini quiz#

Want more? Practise all OOP Concepts MCQs · OOP Concepts interview questions

Related topics#

My notes#

Saved in this browser.