Flyweight Pattern

The Flyweight pattern is a structural design pattern that aims to reduce memory consumption and improve performance by sharing as much data as possible with other similar objects. It’s particularly useful when dealing with a large number of objects that contain redundant data. The core idea is to separate the intrinsic (shared) state from the extrinsic (context-specific) state. The intrinsic state is stored in the Flyweight object, which is shared among multiple clients. The extrinsic state is passed to the Flyweight object by the client when needed, and it determines the object’s specific behavior or appearance in a particular context.

What is Flyweight Pattern

The Flyweight pattern addresses situations where creating and managing a large number of similar objects becomes memory-intensive and inefficient. Imagine a text editor application where each character is represented by an object. Without the Flyweight pattern, each character object would store its font, size, color, and other formatting information, leading to significant memory overhead, especially for large documents.

The Flyweight pattern solves this by separating the character’s intrinsic state (e.g., the character’s ASCII value) from its extrinsic state (e.g., its position, font, color). The intrinsic state is stored in a Flyweight object (the character itself), which is shared among all instances of that character. The extrinsic state is stored externally and passed to the Flyweight object when needed.

In-depth Explanation:

The Flyweight pattern involves the following key components:

Flyweight Interface: Defines the interface through which clients can access and manipulate Flyweight objects.
Concrete Flyweight: Implements the Flyweight interface and stores the intrinsic state. Concrete Flyweight objects are immutable and shared.
Flyweight Factory: Creates and manages Flyweight objects. It ensures that Flyweight objects are shared and reused whenever possible. It typically maintains a pool of Flyweight objects and returns an existing object if one with the required intrinsic state already exists. Otherwise, it creates a new Flyweight object and adds it to the pool.
Client: Holds the extrinsic state and uses the Flyweight objects. The client is responsible for passing the extrinsic state to the Flyweight objects when needed.

Edge Cases:

Immutability: Flyweight objects must be immutable. Their intrinsic state cannot be changed after creation. This is crucial for safe sharing. If the intrinsic state needs to change, a new Flyweight object must be created.
Granularity: The granularity of the Flyweight objects is important. If the intrinsic state is too large, the memory savings may be negligible. If it’s too small, the overhead of managing the Flyweight objects may outweigh the benefits.
Thread Safety: In a multithreaded environment, the Flyweight Factory must be thread-safe to prevent race conditions when creating and accessing Flyweight objects. Consider using mutexes or other synchronization mechanisms.
Context is King: The client must meticulously manage the extrinsic state and correctly pass it to the flyweight. Errors in managing the extrinsic state will lead to incorrect behavior.

Performance Considerations:

Memory Savings: The primary benefit of the Flyweight pattern is memory savings, especially when dealing with a large number of objects with shared intrinsic state.
Performance Overhead: There is some performance overhead associated with the Flyweight pattern, such as the cost of looking up Flyweight objects in the Flyweight Factory and passing the extrinsic state to the Flyweight objects. However, this overhead is typically small compared to the memory savings.
Caching: The Flyweight Factory often uses a cache to store Flyweight objects. The cache should be designed to efficiently retrieve Flyweight objects based on their intrinsic state. Consider using a hash map or other efficient data structure.

Syntax and Usage

The general structure of the Flyweight pattern in C++ is as follows:


#include <iostream>
#include <string>
#include <unordered_map>
 
// Flyweight Interface
class Character {
public:
    virtual void display(int x, int y) = 0;
    virtual ~Character() = default;
};
 
// Concrete Flyweight
class ConcreteCharacter : public Character {
private:
    char character;
 
public:
    ConcreteCharacter(char c) : character(c) {}
 
    void display(int x, int y) override {
        std::cout << "Character: " << character << " at (" << x << ", " << y << ")" << std::endl;
    }
};
 
// Flyweight Factory
class CharacterFactory {
private:
    std::unordered_map<char, Character*> characters;
 
public:
    Character* getCharacter(char c) {
        if (characters.find(c) == characters.end()) {
            characters[c] = new ConcreteCharacter(c);
        }
        return characters[c];
    }
 
    ~CharacterFactory() {
        for (auto const& [key, val] : characters) {
            delete val;
        }
    }
};
 
// Client
int main() {
    CharacterFactory factory;
    Character* a = factory.getCharacter('A');
    Character* b = factory.getCharacter('B');
    Character* a2 = factory.getCharacter('A'); // Reuse existing 'A'
 
    a->display(10, 20);
    b->display(30, 40);
    a2->display(50, 60);
 
    return 0;
}

Basic Example

Let’s consider a more practical example of rendering a document with different fonts and styles.


#include <iostream>
#include <string>
#include <unordered_map>
 
// Intrinsic State: Font data (shared)
struct FontData {
    std::string fontName;
    int fontSize;
    bool isBold;
 
    FontData(std::string name, int size, bool bold) : fontName(name), fontSize(size), isBold(bold) {}
 
    // Overload the == operator for comparison in the unordered_map
    bool operator==(const FontData& other) const {
        return (fontName == other.fontName && fontSize == other.fontSize && isBold == other.isBold);
    }
};
 
// Hash function for FontData (required for unordered_map)
namespace std {
    template <>
    struct hash<FontData> {
        size_t operator()(const FontData& fontData) const {
            size_t hashValue = 17;
            hashValue = hashValue * 31 + std::hash<std::string>{}(fontData.fontName);
            hashValue = hashValue * 31 + std::hash<int>{}(fontData.fontSize);
            hashValue = hashValue * 31 + std::hash<bool>{}(fontData.isBold);
            return hashValue;
        }
    };
}
 
// Flyweight Interface: Glyph (character with formatting)
class Glyph {
public:
    virtual void draw(int x, int y, char character) = 0;
    virtual ~Glyph() = default;
};
 
// Concrete Flyweight: Represents a character with specific font data
class ConcreteGlyph : public Glyph {
private:
    FontData fontData;
 
public:
    ConcreteGlyph(FontData data) : fontData(data) {}
 
    void draw(int x, int y, char character) override {
        std::cout << "Drawing character '" << character << "' at (" << x << ", " << y << ") with font: "
                  << fontData.fontName << ", size: " << fontData.fontSize << ", bold: " << (fontData.isBold ? "true" : "false")
                  << std::endl;
    }
};
 
// Flyweight Factory: Manages and shares Glyph objects
class GlyphFactory {
private:
    std::unordered_map<FontData, Glyph*> glyphs;
 
public:
    Glyph* getGlyph(FontData fontData) {
        if (glyphs.find(fontData) == glyphs.end()) {
            glyphs[fontData] = new ConcreteGlyph(fontData);
        }
        return glyphs[fontData];
    }
 
    ~GlyphFactory() {
        for (auto const& [key, val] : glyphs) {
            delete val;
        }
    }
};
 
// Client: Represents the document
int main() {
    GlyphFactory factory;
 
    // Extrinsic State: Position and character
    int x = 10;
    int y = 20;
 
    // Get Glyphs with different font data
    Glyph* glyph1 = factory.getGlyph({"Arial", 12, false});
    Glyph* glyph2 = factory.getGlyph({"Times New Roman", 14, true});
    Glyph* glyph3 = factory.getGlyph({"Arial", 12, false}); // Reuse glyph1's font
 
    // Draw the characters
    glyph1->draw(x, y, 'H');
    x += 10;
    glyph2->draw(x, y, 'e');
    x += 10;
    glyph3->draw(x, y, 'l');
    x += 10;
    glyph1->draw(x, y, 'l');
    x += 10;
    glyph2->draw(x, y, 'o');
 
    return 0;
}

Explanation:

FontData: Represents the intrinsic state (font name, size, bold). It’s used as the key in the unordered_map, so we need to overload the == operator and provide a hash function.
Glyph is the Flyweight interface.
ConcreteGlyph stores the FontData and implements the draw method.
GlyphFactory manages the ConcreteGlyph objects and ensures they are shared.
The main function (client) creates a GlyphFactory and gets Glyph objects with different font data. It then calls the draw method to render the characters with the specified font and position. The x and y coordinates are the extrinsic state.

Advanced Example

Consider a scenario where you are building a game with a large number of trees. Each tree has a type (e.g., oak, pine, birch) and a position in the world. The tree type (intrinsic state) can be shared among all trees of the same type, while the position (extrinsic state) is unique to each tree.


#include <iostream>
#include <string>
#include <unordered_map>
#include <random>
 
// Intrinsic State: Tree type data (shared)
struct TreeTypeData {
    std::string name;
    std::string texture;
    std::string model;
 
    TreeTypeData(std::string n, std::string t, std::string m) : name(n), texture(t), model(m) {}
 
    bool operator==(const TreeTypeData& other) const {
        return (name == other.name && texture == other.texture && model == other.model);
    }
};
 
namespace std {
    template <>
    struct hash<TreeTypeData> {
        size_t operator()(const TreeTypeData& treeData) const {
            size_t hashValue = 17;
            hashValue = hashValue * 31 + std::hash<std::string>{}(treeData.name);
            hashValue = hashValue * 31 + std::hash<std::string>{}(treeData.texture);
            hashValue = hashValue * 31 + std::hash<std::string>{}(treeData.model);
            return hashValue;
        }
    };
}
 
// Flyweight Interface: Tree
class Tree {
public:
    virtual void draw(int x, int y) = 0;
    virtual ~Tree() = default;
};
 
// Concrete Flyweight: Represents a specific tree type
class ConcreteTree : public Tree {
private:
    TreeTypeData treeTypeData;
 
public:
    ConcreteTree(TreeTypeData data) : treeTypeData(data) {}
 
    void draw(int x, int y) override {
        std::cout << "Drawing " << treeTypeData.name << " tree at (" << x << ", " << y << ") with texture: "
                  << treeTypeData.texture << " and model: " << treeTypeData.model << std::endl;
        // In a real game engine, this would involve rendering the 3D model at the specified position.
    }
};
 
// Flyweight Factory: Manages and shares Tree objects
class TreeFactory {
private:
    std::unordered_map<TreeTypeData, Tree*> trees;
 
public:
    Tree* getTree(TreeTypeData treeTypeData) {
        if (trees.find(treeTypeData) == trees.end()) {
            trees[treeTypeData] = new ConcreteTree(treeTypeData);
        }
        return trees[treeTypeData];
    }
 
    ~TreeFactory() {
        for (auto const& [key, val] : trees) {
            delete val;
        }
    }
};
 
// Client: Represents the game world
int main() {
    TreeFactory factory;
 
    // Tree types
    TreeTypeData oakType("Oak", "oak_texture.png", "oak_model.obj");
    TreeTypeData pineType("Pine", "pine_texture.png", "pine_model.obj");
 
    // Simulate a large number of trees in the world
    std::random_device rd;
    std::mt19937 gen(rd());
    std::uniform_int_distribution<> distrib(0, 999);
 
    for (int i = 0; i < 1000; ++i) {
        int x = distrib(gen);
        int y = distrib(gen);
 
        Tree* tree;
        if (i % 2 == 0) {
            tree = factory.getTree(oakType);
        } else {
            tree = factory.getTree(pineType);
        }
        tree->draw(x, y);
    }
 
    return 0;
}

Common Use Cases

Text Editors: Sharing character formatting information (font, size, color).
Game Development: Sharing textures, models, and other assets among multiple game objects.
Document Processing: Representing and manipulating large documents with shared formatting.
Data Visualization: Displaying large datasets with shared visual properties.

Best Practices

Identify Shared State: Carefully analyze your application to identify the intrinsic state that can be shared among objects.
Ensure Immutability: Make sure that Flyweight objects are immutable to prevent data corruption and ensure safe sharing.
Consider Thread Safety: If your application is multithreaded, ensure that the Flyweight Factory is thread-safe.
Profile Performance: Measure the performance impact of the Flyweight pattern to ensure that it is actually improving performance.

Common Pitfalls

Premature Optimization: Applying the Flyweight pattern without first identifying a performance bottleneck can lead to unnecessary complexity.
Incorrect Granularity: Choosing the wrong granularity for Flyweight objects can negate the benefits of the pattern.
Ignoring Immutability: Failing to ensure that Flyweight objects are immutable can lead to data corruption and unexpected behavior.

Key Takeaways

The Flyweight pattern reduces memory consumption by sharing common parts of objects.
It separates the intrinsic (shared) state from the extrinsic (context-specific) state.
Flyweight objects must be immutable.
The Flyweight Factory manages and shares Flyweight objects.
The Flyweight pattern is useful when dealing with a large number of similar objects.