Flyweight Pattern

A bullet needs an x and y position (an int each, 4 bytes apiece), a color (a short string, call it 10 bytes), and a small 20x20 pixel image (20 x 20 pixels x 3 color channels x 4 bytes per int, which comes out to roughly 4,800 bytes). Add it up and one bullet costs approximately 5,000 bytes — and almost all of that is the image.

Now apply the actual requirement: a multiplayer shooter where 10 players each fire about 10,000 bullets over an hour, for roughly 100,000 bullet objects total. The natural way to model this is one Bullet class holding every property directly.

Run the code below and it works fine — every bullet prints its color, position, and velocity correctly. The bug is not a functional bug. It is a hidden cost that only becomes visible once you multiply by the real object count: at about 5,000 bytes per bullet and 100,000 bullets, total memory for bullets alone comes out to roughly 500,000,000 bytes, or about 500 MB, in a single hour of one multiplayer match. Every one of those bullets is storing its own separate copy of data — especially the image — that is identical, byte for byte, to thousands of other bullets' copies of the exact same data.

class Bullet {
    private String color;   // identical for every bullet of the same color -- but stored separately, every time
    private int x, y;
    private int velocity;

    Bullet(String color, int x, int y, int velocity) {
        this.color = color; this.x = x; this.y = y; this.velocity = velocity;
    }

    void display() {
        System.out.println(color + " bullet at (" + x + "," + y + ") velocity " + velocity);
    }
}

// firing bullets -- five red, five green, each a fully separate object
for (int i = 0; i < 5; i++) {
    new Bullet("Red", i * 10, i * 12, 5);
}
for (int i = 0; i < 5; i++) {
    new Bullet("Green", i * 10, i * 12, 5);
}
// every "Red" bullet stores its own independent copy of the string "Red", and (in a real game) its own copy of the bullet image

Look closely at what actually varies between bullets, and what does not.

1. Some properties are genuinely identical across many bullets. Every red bullet has the exact same color, and in a fuller version, the exact same image. These are called intrinsic properties: shared, reusable, and safe to store exactly once.
2. Some properties are genuinely unique to each individual bullet. Its x and y position, its velocity. These are called extrinsic properties: they can never be shared, because they differ for every single instance.
3. So intrinsic properties should be pulled out into their own shared object, and every bullet that needs "red" should hold a reference to that one shared object, instead of its own independent copy.

This split — intrinsic state shared and stored once, extrinsic state kept per instance — is the Flyweight pattern. It dramatically reduces memory whenever many instances share the same intrinsic data.

The implementation has two pieces. First, a flyweight class that holds only the intrinsic, shareable state — nothing about position or velocity belongs here at all. Second, a factory that guarantees only one flyweight instance ever gets constructed per unique combination of intrinsic properties. Without that factory, nothing stops the same BulletType("Red") from being constructed a hundred thousand times, which would defeat the entire point.

The factory's job is the same underlying question a Singleton answers — "who is responsible for making sure we don't create a duplicate?" — just generalized from one single instance total to one instance per unique key. It keeps a cache, checks it before constructing anything, and returns the same shared object every time the same key is requested.

Once the factory exists, Bullet itself changes to match: instead of storing color directly, it stores a reference to a shared BulletType, obtained by asking the factory for it.

class BulletType { // the FLYWEIGHT -- this is what gets shared across thousands of bullets
    private final String color; // no x, no y, no velocity -- genuinely per-bullet data has no place here

    public BulletType(String color) {
        this.color = color;
        System.out.println("Creating bullet type with color: " + color); // only ever printed once per unique color
    }
}

class BulletTypeFactory {
    private static final Map<String, BulletType> bulletTypes = new HashMap<>(); // static: ONE cache, shared across the whole application

    public static BulletType getBulletType(String color) {
        if (!bulletTypes.containsKey(color)) {              // has this exact color been requested before?
            bulletTypes.put(color, new BulletType(color)); // no -- construct it ONCE, and remember it
        }
        return bulletTypes.get(color);                    // yes, or just constructed -- either way, return the SAME shared instance
    }
}

class Bullet {
    private BulletType type; // intrinsic state -- a shared reference, not a duplicated copy
    private int x, y;        // extrinsic state -- genuinely unique to THIS bullet
    private int velocity;

    Bullet(String color, int x, int y, int velocity) {
        this.type = BulletTypeFactory.getBulletType(color); // reuses an existing BulletType if one already exists for this color
        this.x = x; this.y = y; this.velocity = velocity;
    }
}

The client code that fires bullets does not change at all. It calls new Bullet("Red", ...) exactly the way it did before the refactor — the sharing happens entirely inside the constructor, invisible to whoever is creating bullets. That is worth noticing: a well-applied Flyweight changes how data is stored internally without forcing every caller to change how they use the class.

Running the same loop that fires five red bullets and five green bullets now prints "Creating bullet type with color: Red" exactly once, and "Creating bullet type with color: Green" exactly once — not five times each. Every one of the five red Bullet instances shares the same single BulletType object in memory; only their x, y, and velocity differ.

Now redo the memory math from before, with the flyweight in place. Each Bullet stores only a reference to its BulletType (a handful of bytes, not the full ~5,000) plus its genuinely unique x, y, and velocity (about 8 to 12 bytes total). The ~5,000-byte cost is now paid once per unique color, not once per bullet.

	Without Flyweight	With Flyweight
Per-bullet cost	~5,000 bytes (color + image duplicated every time)	~8 bytes (just x, y -- a reference is nearly free)
Shared cost	--	~5,000 bytes x 2 colors = 10,000 bytes, paid once
Total (100,000 bullets)	~500,000,000 bytes, about 500 MB	~800,000 + 10,000 bytes, about 0.8 MB

That is roughly a 600x reduction in memory — not a rounding difference, but the entire reason this pattern exists. Gameplay logic and rendering are completely unaffected; only how the underlying data is stored changed.

public class Game {
    public static void main(String[] args) {
        for (int i = 0; i < 5; i++) {
            new Bullet("Red", i * 10, i * 12, 5); // same call signature as before -- nothing about USING Bullet changed
        }
        for (int i = 0; i < 5; i++) {
            new Bullet("Green", i * 10, i * 12, 5);
        }
        // output: "Creating bullet type with color: Red" printed ONCE, then "...Green" printed ONCE -- not five times each
    }
}

Flyweight is a genuine, worthwhile optimization for exactly one shape of problem: enormous object counts with substantial shared state. It is also arguably the most niche pattern a working developer will run into. Applying it to a game with a handful of bullets on screen at once, or to data that is mostly unique per instance anyway, adds real complexity — the split between intrinsic and extrinsic state, a factory managing a cache — for a memory saving that was never actually needed. Confirm there is a genuine, measured memory problem, the way the earlier math confirmed one here, before reaching for this pattern.