Lazy Load Strategy Implementer

When to Use

You have an object graph backed by a relational database. Loading some objects eagerly pulls in far more data than any single use case needs — but loading objects lazily without discipline produces N+1 queries (one database call per object in a collection) or ripple loading (a cascade of individual loads triggered across the graph).

Apply this skill when:

• A query log shows N+1 round-trips for a collection
• A single user action triggers dozens of database calls
• Memory or startup latency is unacceptable due to eager-loading large associations
• You are configuring or auditing ORM fetch strategies

Do not apply Lazy Load when:

• The object is always needed immediately after loading its parent (eager load with a fetch-join is simpler)
• The collection is always iterated in full by the first use case that loads the parent (eager load it)
• The application uses a very small, bounded dataset (load everything upfront)

Prerequisite: know which data-source pattern the codebase uses. If unclear, invoke data-source-pattern-selector first, or ask the user. Lazy Load implementation differs significantly between hand-rolled Active Record (Lazy Initialization is simplest) and Data Mapper / ORM (Virtual Proxy or Ghost are standard).