Flyweight pattern in LLD - System Design Exercise

Design: Flyweight Pattern Implementation

Design the Flyweight pattern structure and usage for a system that needs many similar objects with shared state. Out of scope: specific application domain details or UI integration.

Functional Requirements

FR1: Support creation of many similar objects efficiently

FR2: Share common intrinsic state among objects to save memory

FR3: Allow extrinsic state to be supplied externally when needed

FR4: Provide a way to manage and reuse shared objects

FR5: Ensure thread-safe access to shared objects if used concurrently

Non-Functional Requirements

NFR1: Must reduce memory usage significantly compared to naive object creation

NFR2: Should not compromise performance when accessing shared objects

NFR3: Design should be simple to integrate into existing systems

NFR4: Support up to 1 million objects with limited memory overhead

NFR5: Latency for object retrieval should be under 5ms

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Flyweight interface defining shared behavior

Concrete Flyweight objects holding intrinsic state

Flyweight Factory to manage and reuse flyweight instances

Client code supplying extrinsic state when using flyweights

Design Patterns

Flyweight pattern for memory optimization

Factory pattern for object creation and reuse

Caching strategies for efficient retrieval

Thread-safe singleton or pool for flyweight factory

Reference Architecture

Client
  |
  v
Flyweight Factory <----> Shared Flyweight Objects
  |
  v
Extrinsic State supplied by Client

Legend:
- Client requests flyweight from Factory
- Factory returns shared flyweight object
- Client uses flyweight with extrinsic state

Components

Flyweight Interface

Abstract class or interface in chosen language

Defines methods that flyweight objects must implement

Concrete Flyweight

Class implementing Flyweight Interface

Holds intrinsic (shared) state and implements behavior

Flyweight Factory

Singleton or static class

Creates and manages shared flyweight instances, returns existing ones if available

Client

Any application code

Requests flyweights from factory and supplies extrinsic state when using them

Request Flow

1. Client requests a flyweight object from the Flyweight Factory with a key representing intrinsic state

2. Factory checks if a flyweight with that intrinsic state exists

3. If exists, Factory returns the existing flyweight object

4. If not, Factory creates a new Concrete Flyweight with intrinsic state and stores it

5. Client receives the flyweight object

6. Client uses the flyweight object by passing extrinsic state as needed for operations

Database Schema

Not applicable as Flyweight pattern is a design pattern for in-memory object sharing, no persistent storage schema required.

Scaling Discussion

Bottlenecks

Factory lookup time increases with number of flyweights

Memory overhead if intrinsic state is not properly shared

Thread contention if factory is accessed concurrently without synchronization

Garbage collection pressure if many flyweights are created and discarded

Solutions

Use efficient data structures like hash maps for factory lookup

Carefully identify and separate intrinsic vs extrinsic state to maximize sharing

Implement thread-safe factory using locks or concurrent data structures

Use weak references or caching policies to allow unused flyweights to be garbage collected

Interview Tips

Time: Spend 10 minutes explaining the problem and pattern concept, 15 minutes designing the components and data flow, 10 minutes discussing scaling and trade-offs, 10 minutes answering questions.

Explain difference between intrinsic and extrinsic state clearly

Describe how factory manages shared objects and avoids duplication

Discuss thread safety and memory optimization benefits

Mention real-world examples like text editors sharing character glyphs

Highlight trade-offs between complexity and memory savings

Practice

1. What is the main purpose of the Flyweight pattern in system design?

easy

A. To encrypt data for security

B. To save memory by sharing common parts of objects

C. To improve network communication speed

D. To create new objects for every request

Solution

1. Step 1: Understand the Flyweight pattern goal

   The Flyweight pattern focuses on reducing memory usage by sharing common data among many objects.

2. Step 2: Compare options with the pattern goal

   Only To save memory by sharing common parts of objects matches the purpose of saving memory by sharing parts of objects.

3. Final Answer:

   To save memory by sharing common parts of objects -> Option B

4. Quick Check:

   Flyweight = Memory sharing [OK]

Hint: Flyweight shares data to save memory, not speed or security [OK]

Common Mistakes:

• Confusing Flyweight with caching or encryption
• Thinking Flyweight creates new objects each time
• Mixing Flyweight with network optimization

2. Which of the following is the correct way to separate intrinsic and extrinsic state in a Flyweight object?

easy

A. Store shared data inside the Flyweight and pass unique data externally

B. Do not separate data; treat all data as shared

C. Keep all data inside the Flyweight object

D. Store unique data inside the Flyweight and shared data outside

Solution

1. Step 1: Recall Flyweight data separation

   Flyweight stores intrinsic (shared) data internally and receives extrinsic (unique) data externally.

2. Step 2: Match options with this rule

   Store shared data inside the Flyweight and pass unique data externally correctly states shared data inside Flyweight and unique data passed externally.

3. Final Answer:

   Store shared data inside the Flyweight and pass unique data externally -> Option A

4. Quick Check:

   Intrinsic inside, extrinsic outside [OK]

Hint: Flyweight holds shared data; unique data comes from outside [OK]

Common Mistakes:

• Putting unique data inside Flyweight causing duplication
• Not separating data leading to memory waste
• Confusing intrinsic and extrinsic states

3. Consider this simplified Flyweight usage in code:

class TreeType:
    def __init__(self, name, color):
        self.name = name
        self.color = color

class TreeFactory:
    _tree_types = {}

    @classmethod
    def get_tree_type(cls, name, color):
        key = (name, color)
        if key not in cls._tree_types:
            cls._tree_types[key] = TreeType(name, color)
        return cls._tree_types[key]

# Usage
factory = TreeFactory()
t1 = factory.get_tree_type('Oak', 'Green')
t2 = factory.get_tree_type('Oak', 'Green')
t3 = factory.get_tree_type('Pine', 'Green')
print(t1 is t2, t1 is t3)

What will be the output?

medium

A. True False

B. False True

C. True True

D. False False

Solution

1. Step 1: Understand object sharing in factory

   The factory returns the same TreeType object for identical (name, color) keys, so t1 and t2 share the same object.

2. Step 2: Compare object identities

   t1 is t2 will be True because they share the same instance; t1 is t3 will be False because 'Pine' differs from 'Oak'.

3. Final Answer:

   True False -> Option A

4. Quick Check:

   Shared keys = same object [OK]

Hint: Same key returns same object, different key returns new object [OK]

Common Mistakes:

• Assuming all objects are different
• Ignoring the factory cache
• Confusing identity (is) with equality (==)

4. In this Flyweight implementation snippet, what is the main error?

class Flyweight:
    def __init__(self, shared_state):
        self.shared_state = shared_state

class FlyweightFactory:
    def __init__(self):
        self._flyweights = {}

    def get_flyweight(self, shared_state):
        if shared_state not in self._flyweights:
            self._flyweights[shared_state] = Flyweight(shared_state)
        return self._flyweights[shared_state]

medium

A. Creating new Flyweight every time

B. Not storing unique data inside Flyweight

C. Using mutable type as dictionary key without hashing

D. Missing constructor in Flyweight class

Solution

1. Step 1: Identify dictionary key usage

   The code uses shared_state as a dictionary key, but if shared_state is a mutable type like a list or dict, it cannot be used as a key.

2. Step 2: Understand dictionary key requirements

   Dictionary keys must be immutable and hashable; using mutable types causes runtime errors.

3. Final Answer:

   Using mutable type as dictionary key without hashing -> Option C

4. Quick Check:

   Dict keys must be immutable [OK]

Hint: Dict keys must be immutable; mutable keys cause errors [OK]

Common Mistakes:

• Ignoring type of shared_state as dict key
• Assuming Flyweight always stores unique data
• Overlooking constructor presence

5. You are designing a text editor that displays millions of characters. Each character has a font style and color (shared), and a position (unique). How would you apply the Flyweight pattern here to optimize memory?

hard

A. Store position inside Flyweight and font/color externally

B. Store all data inside Flyweight objects without separation

C. Create a new object for every character without sharing

D. Create a Flyweight object for each unique character with its font and color, pass position externally

Solution

1. Step 1: Identify intrinsic and extrinsic data

   Font style and color are shared (intrinsic), position is unique (extrinsic) for each character.

2. Step 2: Apply Flyweight pattern correctly

   Create Flyweight objects for shared font and color, pass position externally when rendering characters.

3. Final Answer:

   Create a Flyweight object for each unique character with its font and color, pass position externally -> Option D

4. Quick Check:

   Shared data in Flyweight, unique data outside [OK]

Hint: Flyweight holds shared style; position passed externally [OK]

Common Mistakes:

• Putting position inside Flyweight causing many objects
• Not sharing font and color data
• Ignoring separation of intrinsic and extrinsic data