Skip to content
wannacode

Singleton and Dependency Injection

In short: Singleton guarantees a single instance of a class, while Dependency Injection passes dependencies in from outside, so the code can be tested with a substitute, such as a clock.

Problem

The test that passes only on Fridays

On Fridays the shop gives a 10% discount. The program has one clock, so it is a Singleton: a class with only one object, reachable from anywhere. The order service asks it what day it is:

class SystemClock {
  today() {
    return new Date();
  }
}


const clock = new SystemClock();


const FRIDAY = 5;


class OrderService {
  price(amount) {
    if (clock.today().getDay() === FRIDAY) {
      return amount * 0.9;
    }
    return amount;
  }
}

Someone writes a test to make sure the discount works:

const service = new OrderService();
console.log(`Friday discount: expected €90.00, got €${service.price(100).toFixed(2)}`);

Run on Monday, October 26, 2026, the test prints:

Output
Friday discount: expected €90.00, got €100.00

On a Friday the same test prints 90.00. The test passes one day a week and fails on the other six, and the code is the same. To check the discount you have to wait for Friday or move the computer's clock.

The clock itself is done right. The problem is that price reaches for it itself. From outside you can't see that the service depends on a clock: new OrderService() asks for nothing. The test can't give it another day, because it can't give it anything.

The idea

The one object and handing it in

A Singleton guarantees two things: there is only one object, and anyone can take it from anywhere. The first is sometimes needed. The second is the price:

  • a hidden dependency. Who uses the clock shows only if you read every line of every method;
  • shared state. Whatever one piece of code changes in the object, everyone else sees, including the next test;
  • it can't be swapped. The code points to the concrete class by name. Another clock for the test has no way in.

The fix is not to remove the clock, but to hand it in from outside. The service doesn't look for its dependency, it receives it in the constructor. Which clock it is, is decided by whoever creates the service: the program hands in the real one, and the test its own, with a date the test picks.

This is called Dependency Injection (DI). There are three roles:

  • the service says what it needs: a parameter in the constructor. What the object is doesn't matter, as long as it has a today() method;
  • the dependency is the object it is given: the real clock or the test one;
  • the wiring happens in one place, at the start of the program. That is where you decide which object goes where.

The Singleton can even stay: the one clock is handed in like any other object. Nobody just reaches for it on their own.

See it

Singleton, the way the language gives it

In the lesson "Design patterns" you saw a Singleton as a class that keeps its one object. In JavaScript it is rarely done that way, because the language already has something that runs only once: the module.A module (the file clock.js) runs once, on the first import. Every later import { clock } from "./clock.js" gives the same object. An object exported from a module with export is a Singleton without a single extra line of code:
class SystemClock {
  constructor() {
    console.log("Creating the clock");
  }


  today() {
    return new Date();
  }
}


export const clock = new SystemClock();
console.log("Start");
Output
Creating the clock
Start
The object is created when the module runs, before the first line that uses it. In this program the module and the code are in one file. In a real project the clock is in its own file, and however many places import it, there is one object.
More precisely, if you are curious
With require (CommonJS, the older kind of module in Node.js) it is the same: the module runs on the first require, and later ones get its ready result.

See it

The clock comes in from outside

The service asks for a clock in its constructor. What it is doesn't matter, as long as it has a today() method. The module with clock stays the same:
const FRIDAY = 5;


class OrderService {
  constructor(clock) {
    this.clock = clock;
  }


  price(amount) {
    if (this.clock.today().getDay() === FRIDAY) {
      return amount * 0.9;
    }
    return amount;
  }
}

In the program, the real clock is handed in once, at creation:

const service = new OrderService(clock);

Now new OrderService(...) says out loud that it can't work without a clock. The dependency shows in the constructor's signature, not somewhere inside a method.

See it

The test picks the day itself

The test needs a clock you can tell which date to return:

class FakeClock {
  constructor(date) {
    this.date = date;
  }


  today() {
    return this.date;
  }
}

The test hands it in instead of the real one:

const clock = new FakeClock(new Date(2026, 9, 30));
const service = new OrderService(clock);
console.log(`Friday: €${service.price(100).toFixed(2)}`);


clock.date = new Date(2026, 9, 27);
console.log(`Tuesday: €${service.price(100).toFixed(2)}`);
Output
Friday: €90.00
Tuesday: €100.00

const clock = new FakeClock(new Date(2026, 9, 30));
const service = new OrderService(clock);
console.log(`Friday: €${service.price(100).toFixed(2)}`);


clock.date = new Date(2026, 9, 27);
console.log(`Tuesday: €${service.price(100).toFixed(2)}`);
Step by step, in words
  1. Before, price reached for the module-level clock itself: a hidden link to a global object the test cannot change.
  2. The test makes its own clock: a FakeClock that says 2026-10-30, a Friday.
  3. The clock comes in from outside, through the constructor. OrderService only keeps a reference to it.
  4. price(100): the service asks its clock. It's a Friday, so the sum is 90.00.
  5. The test moves the date to 2026-10-27, a Tuesday. Nothing in OrderService changes.
  6. The same price(100): a Tuesday, 100.00. The test gives these two numbers on any day of the week.
Months in Date count from 0: new Date(2026, 9, 30) is October 30.

The test gives these two numbers on a Monday, on a Friday and on a Sunday. OrderService is the same class that runs in the shop: the test changes only what it hands in.

More precisely, if you are curious
A clock with one method can also be a plain object: { today: () => new Date(2026, 9, 30) }. No class is needed: the service only needs a today() method.

Try it

Predict the output

The classes are from the cards before this one. October 31, 2026 is a Saturday. What does the program print?

const clock = new FakeClock(new Date(2026, 9, 30));
const shop = new OrderService(clock);
clock.date = new Date(2026, 9, 31);
const app = new OrderService(clock);


console.log(`€${shop.price(50).toFixed(2)}`);
console.log(`€${app.price(50).toFixed(2)}`);
Answer

Try it

Find the bug

The cart is a Singleton, "so that there is one":

class Cart {
  constructor() {
    this.items = [];
  }


  add(item) {
    this.items.push(item);
  }
}


const cart = new Cart();

Two tests, each with its own checkout page. check prints OK or what the test expected:

const first = new CheckoutPage();
first.add("Coffee");
first.add("Mug");
check("Test 1", first.count(), 2);


const second = new CheckoutPage();
second.add("Coffee");
check("Test 2", second.count(), 1);
Output
Test 1: OK
Test 2: FAIL, expected 1, got 3

Each test passes on its own. Together, the second fails. Which line has the bug?

Pick the line with the bug.

More precisely, if you are curious

Test libraries run tests in an order that is not guaranteed, sometimes at the same time. A test that passes only when it runs first is a test that fails at random. Shared state in a Singleton is the most common cause.

The idea

When you don't need it

A Singleton makes sense when a second copy would be a mistake and the object keeps nothing that changes: settings read once at startup, the log, the pool of database connections. Even then it is better handed in from outside than reached for by everyone.

Handing in from outside has a price too. It's not worth it when:

  • the dependency never changes and doesn't get in the way of tests. Math.round is not a dependency you hand in;
  • the program is small. Wiring by hand in the start of the program is enough; a DI framework is for big applications;
  • the constructor asks for eight dependencies. That's not a DI problem: the class does too much.

Exercise

Black Friday

Solve the task in your editor.

Black Friday. On November 27, 2026 the shop gives a 30% discount, and on other Fridays still 10%. Add the rule to OrderService and check it with FakeClock for three dates: Black Friday, October 30 (a Friday) and October 27 (a Tuesday). The test gives the same output on any day.

Output
Black Friday: €70.00
Friday: €90.00
Tuesday: €100.00

More tasks

  • Order numbers. The counter for order numbers is a Singleton and starts at 1001. Make it a dependency of OrderService and write two tests that both get 1001 as the first number.
  • A cart for every customer. Fix the bug from "Find the bug" all the way: the cart is not a Singleton, and every page gets its own. Two customers add different items, and each sees only their own.
  • Night discount. Between 22:00 and 6:00 the discount is 5%. The clock now has to give the hour too. What do you change in the clock, and how many tests do you need to be sure?

Test

Check yourself

1. Why does the test for the Friday discount pass only on Fridays?
2. What does handing in the dependency (Dependency Injection) change?
3. Two tests use the same cart, a Singleton. The first adds two items, the second adds one and expects 1. What happens?
4. When is a Singleton in place?

Made by Ivo Gergov as part of Evo Tech's campaign for accessible programming education ·