79:T922,// The Problem: Each document creation repeats expensive initialization class DocumentTemplate { private readonly styles: Map; private readonly sections: Section[]; private readonly resources: EmbeddedResource[]; private readonly validationSchema: ValidationSchema; constructor(templateId: string) { // EXPENSIVE: Database query to load template definition const templateDef = this.loadFromDatabase(templateId); // EXPENSIVE: Parse complex XML structure this.styles = this.parseStyleDefinitions(templateDef.stylesXml); // EXPENSIVE: Initialize and validate sections this.sections = this.initializeSections(templateDef.sectionData); // EXPENSIVE: Load binary resources from storage this.resources = this.loadEmbeddedResources(templateDef.resourceIds); // EXPENSIVE: Compile validation schema this.validationSchema = this.compileSchema(templateDef.schemaDefinition); } private loadFromDatabase(templateId: string): TemplateDef { // 200ms database round-trip console.log(`Loading template ${templateId} from database...`); return {} as TemplateDef; } private parseStyleDefinitions(xml: string): Map { // 50ms XML parsing console.log("Parsing style definitions..."); return new Map(); } private initializeSections(data: SectionData[]): Section[] { // 30ms per section console.log("Initializing sections..."); return []; } private loadEmbeddedResources(ids: string[]): EmbeddedResource[] { // 100ms storage access per resource console.log("Loading embedded resources..."); return []; } private compileSchema(def: SchemaDefinition): ValidationSchema { // 75ms schema compilation console.log("Compiling validation schema..."); return {} as ValidationSchema; } } // Creating 10 documents from the same template = 10x initialization cost // Total: ~4.5 seconds (10 × 450ms) for operations that could be instantaneous for (let i = 0; i < 10; i++) { const doc = new DocumentTemplate("invoice-template"); // Each iteration: 450ms+ of redundant initialization }7a:T9f3,// The Problem: Each document creation repeats expensive initialization public class DocumentTemplate { private final Map styles; private final List

sections; private final List resources; private final ValidationSchema validationSchema; public DocumentTemplate(String templateId) { // EXPENSIVE: Database query to load template definition TemplateDef templateDef = loadFromDatabase(templateId); // EXPENSIVE: Parse complex XML structure this.styles = parseStyleDefinitions(templateDef.getStylesXml()); // EXPENSIVE: Initialize and validate sections this.sections = initializeSections(templateDef.getSectionData()); // EXPENSIVE: Load binary resources from storage this.resources = loadEmbeddedResources(templateDef.getResourceIds()); // EXPENSIVE: Compile validation schema this.validationSchema = compileSchema(templateDef.getSchemaDefinition()); } private TemplateDef loadFromDatabase(String templateId) { // 200ms database round-trip System.out.println("Loading template " + templateId + " from database..."); return new TemplateDef(); } private Map parseStyleDefinitions(String xml) { // 50ms XML parsing System.out.println("Parsing style definitions..."); return new HashMap<>(); } private List

initializeSections(List data) { // 30ms per section System.out.println("Initializing sections..."); return new ArrayList<>(); } private List loadEmbeddedResources(List ids) { // 100ms storage access per resource System.out.println("Loading embedded resources..."); return new ArrayList<>(); } private ValidationSchema compileSchema(SchemaDefinition def) { // 75ms schema compilation System.out.println("Compiling validation schema..."); return new ValidationSchema(); } } // Creating 10 documents from the same template = 10x initialization cost // Total: ~4.5 seconds (10 × 450ms) for operations that could be instantaneous public class Main { public static void main(String[] args) { for (int i = 0; i < 10; i++) { DocumentTemplate doc = new DocumentTemplate("invoice-template"); // Each iteration: 450ms+ of redundant initialization } } }7b:T85f,// ANTIPATTERN: Type-switching to create copies // This violates Open/Closed Principle and becomes unmaintainable interface Shape { draw(): void; getColor(): string; } class Circle implements Shape { constructor( public readonly radius: number, public readonly color: string, public readonly lineWidth: number ) {} draw(): void { /* ... */ } getColor(): string { return this.color; } } class Rectangle implements Shape { constructor( public readonly width: number, public readonly height: number, public readonly color: string, public readonly lineWidth: number ) {} draw(): void { /* ... */ } getColor(): string { return this.color; } } class Triangle implements Shape { constructor( public readonly sideA: number, public readonly sideB: number, public readonly sideC: number, public readonly color: string, public readonly lineWidth: number ) {} draw(): void { /* ... */ } getColor(): string { return this.color; } } // The problem: creating a copy of an abstract Shape reference function copyShape(shape: Shape): Shape { // We MUST know every concrete type! // Adding a new shape type requires modifying this function if (shape instanceof Circle) { return new Circle(shape.radius, shape.color, shape.lineWidth); } else if (shape instanceof Rectangle) { return new Rectangle(shape.width, shape.height, shape.color, shape.lineWidth); } else if (shape instanceof Triangle) { return new Triangle(shape.sideA, shape.sideB, shape.sideC, shape.color, shape.lineWidth); } // What about new shape types? This function must be updated! // What about shapes defined in plugins we haven't loaded yet? throw new Error(`Unknown shape type: ${shape.constructor.name}`); } // Real-world scenario: A graphics editor loads shape plugins dynamically // The editor core cannot possibly know about user-installed shape types // This approach fundamentally cannot work for extensible systems7c:Tca4,// The Problem: Complex configuration that's tedious to replicate interface ReportConfiguration { title: string; columns: ColumnDefinition[]; filters: FilterCriteria[]; sorting: SortOrder[]; grouping: GroupingConfig | null; aggregations: AggregationConfig[]; formatting: FormattingOptions; exportSettings: ExportSettings; permissions: PermissionSet; scheduling: ScheduleConfig | null; } class ReportBuilder { private config: Partial = {}; // Each user spends 10-20 clicks configuring a report setTitle(title: string): this { this.config.title = title; return this; } addColumn(column: ColumnDefinition): this { this.config.columns = [...(this.config.columns || []), column]; return this; } addFilter(filter: FilterCriteria): this { this.config.filters = [...(this.config.filters || []), filter]; return this; } setSorting(sorting: SortOrder[]): this { this.config.sorting = sorting; return this; } setGrouping(grouping: GroupingConfig): this { this.config.grouping = grouping; return this; } addAggregation(agg: AggregationConfig): this { this.config.aggregations = [...(this.config.aggregations || []), agg]; return this; } setFormatting(options: FormattingOptions): this { this.config.formatting = options; return this; } setExportSettings(settings: ExportSettings): this { this.config.exportSettings = settings; return this; } setPermissions(permissions: PermissionSet): this { this.config.permissions = permissions; return this; } setSchedule(schedule: ScheduleConfig): this { this.config.scheduling = schedule; return this; } build(): Report { return new Report(this.config as ReportConfiguration); } } // User carefully configures a sales report through the UI const salesReport = new ReportBuilder() .setTitle("Q4 Sales by Region") .addColumn({ name: "Region", type: "string" }) .addColumn({ name: "Sales", type: "currency" }) .addColumn({ name: "Growth", type: "percentage" }) .addFilter({ field: "Year", operator: "eq", value: 2024 }) .addFilter({ field: "Quarter", operator: "eq", value: "Q4" }) .setSorting([{ field: "Sales", direction: "desc" }]) .setGrouping({ field: "Region", aggregateChildren: true }) .addAggregation({ field: "Sales", function: "sum" }) .addAggregation({ field: "Growth", function: "avg" }) .setFormatting({ currency: "USD", dateFormat: "MM/DD/YYYY" }) .setExportSettings({ format: "xlsx", includeCharts: true }) .setPermissions({ viewable: ["sales-team"], editable: ["managers"] }) .setSchedule({ frequency: "weekly", day: "Monday", time: "08:00" }) .build(); // Now the user wants a similar report for Q3 // WITHOUT cloning, they must repeat the entire 15-step configuration // WITH cloning, they copy the report and change only what differs // What we need: // const q3Report = salesReport.clone() // .setTitle("Q3 Sales by Region") // .updateFilter("Quarter", "Q3");7d:T7c9,// The Problem: Factory Method leads to subclass explosion // Each new button style requires a new factory class // Product interface interface Button { render(): void; } // Concrete products - and there could be many more class PrimaryButton implements Button { render(): void { console.log("Rendering primary button"); } } class SecondaryButton implements Button { render(): void { console.log("Rendering secondary button"); } } class DangerButton implements Button { render(): void { console.log("Rendering danger button"); } } class GhostButton implements Button { render(): void { console.log("Rendering ghost button"); } } class LinkButton implements Button { render(): void { console.log("Rendering link button"); } } // PROBLEM: Factory Method requires parallel factory hierarchy abstract class ButtonFactory { abstract createButton(): Button; } // Each product type needs a corresponding factory class! class PrimaryButtonFactory extends ButtonFactory { createButton(): Button { return new PrimaryButton(); } } class SecondaryButtonFactory extends ButtonFactory { createButton(): Button { return new SecondaryButton(); } } class DangerButtonFactory extends ButtonFactory { createButton(): Button { return new DangerButton(); } } class GhostButtonFactory extends ButtonFactory { createButton(): Button { return new GhostButton(); } } class LinkButtonFactory extends ButtonFactory { createButton(): Button { return new LinkButton(); } } // With 20 button variants: 20 product classes + 20 factory classes = 40 classes // With 50 button variants: 50 product classes + 50 factory classes = 100 classes // And this doesn't even account for variations like: // - PrimarySmallButton, PrimaryLargeButton // - DangerRoundedButton, DangerSquareButton // - Each combination would traditionally require its own factory // The Prototype Pattern eliminates the parallel factory hierarchy entirely // by letting objects clone themselves71:{"json":{"id":"seed_d5231270cfb85d748c94b9b1e2cf31c5","slug":"prototype-pattern","category":"System Design (LLD)","topic":"Prototype Pattern","title":"Prototype Pattern: Object Cloning for Efficient Creation","description":"Master the Prototype Pattern for creating objects by copying existing instances. Learn when cloning outperforms instantiation, understand shallow vs deep copy semantics, implement prototype registries, and apply this pattern effectively in real-world systems.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_0970e64c595fa8d538e9e2c5531fcd64","title":"Problem: Creating Objects by Copying Existing Ones","order":0,"content":[{"id":"opening-hook","title":"When Creating Objects the Normal Way Fails","content":[{"data":{"content":"In object-oriented programming, we typically create objects using constructors—invoking `new` with a class name and passing constructor arguments. This approach works well for most scenarios, but certain situations reveal its fundamental limitations:\n\nWhat if **you don't know the concrete class** at compile time? What if object creation is **prohibitively expensive** and you need many similar copies? What if the object's **configuration is complex** and you want to preserve a pre-configured state as a template?\n\nThese scenarios point to a fundamentally different approach to object creation: **copying existing objects rather than constructing new ones from scratch**. This is the domain of the **Prototype Pattern**—one of the original Gang of Four creational patterns that remains surprisingly relevant in modern software development."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the specific problems that make object cloning preferable to traditional instantiation. You'll recognize pattern signatures in your own code that suggest the Prototype Pattern, and you'll understand why this pattern exists as a first-class creational mechanism alongside factories and builders.","variant":"info"},"type":"callout"}]},{"id":"fundamental-tension","title":"The Fundamental Tension in Object Creation","content":[{"data":{"content":"Every object-oriented system must address a fundamental question: **How do we create objects in a way that maintains flexibility, encapsulation, and performance?**\n\nTraditional constructor-based creation has several inherent constraints that become problematic in specific scenarios:"},"type":"text"},{"data":{"items":["**Static Binding** — The `new` keyword binds to a specific class at compile time. This creates tight coupling between the creating code and the concrete class being instantiated.","**Repeated Initialization Cost** — Each `new` invocation executes the full initialization sequence, even when creating many similar objects that share most of their configuration.","**Knowledge Requirements** — The caller must know the exact class and all required constructor parameters. This exposes implementation details and violates encapsulation.","**Configuration Complexity** — Objects with complex setup requirements force callers to understand intricate initialization sequences that should be hidden.","**Runtime Type Discovery** — When the concrete type is determined at runtime (e.g., from configuration or user input), constructor-based creation requires explicit type-switching logic."],"title":{"icon":"AlertCircle","text":"Constraints of Constructor-Based Creation","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The core insight:**\n\nWhen you already have a valid, properly-configured instance of an object, that **existing object itself becomes the best specification** for creating similar objects. The object knows its own type, its own state, and its own structure—information that would otherwise need to be replicated in factory methods or complex constructor calls.\n\nThis realization leads to a different philosophy of object creation: **let objects create copies of themselves**."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"expensive-creation","title":"Problem Domain: Expensive Object Creation","content":[{"data":{"content":"The most straightforward motivation for the Prototype Pattern emerges when **object creation is expensive**—when the cost of instantiating a new object from scratch significantly exceeds the cost of copying an existing one.\n\nConsider what happens during object construction:"},"type":"text"},{"data":{"rows":[["Database Queries","Loading entity relationships from DB","50-500ms per object","Yes — clone pre-loaded state"],["Network Requests","Fetching configuration from remote service","100-2000ms latency","Yes — clone cached responses"],["File I/O","Reading template files, parsing XML/JSON","10-100ms depending on size","Yes — clone parsed structure"],["Complex Calculations","Generating cryptographic keys, computing layouts","Variable, potentially seconds","Yes — clone computed results"],["External Resource Allocation","Acquiring database connections, thread pools","Significant overhead","Partially — may require adjustments"]],"caption":"Expensive Operations During Object Construction","headers":["Operation Type","Example Scenario","Typical Cost","Avoidable Via Cloning?"]},"type":"table"},{"data":{"content":"**A concrete example: Document Templates**\n\nImagine a document management system where users create documents from templates. Each template contains:\n- Complex formatting rules (hundreds of style definitions)\n- Pre-configured sections with placeholder text\n- Embedded resources (logos, watermarks, fonts)\n- Validation schemas for different content types\n\nLoading a template from the database involves multiple queries, parsing XML structures, and initializing internal caches. Without cloning, every new document requires this expensive initialization—even when users create dozens of similar documents in sequence."},"type":"text"},{"data":{"fileName":"expensive-creation-problem.ts","languages":[{"code":"$79","label":"TypeScript","value":"typescript"},{"code":"$7a","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"The Hidden Cumulative Cost","content":"In many systems, expensive object creation doesn't manifest as a single slow operation—it appears as cumulative latency across many 'small' creations. A 200ms initialization repeated 50 times in a request cycle becomes 10 seconds of blocked processing. Profiling often reveals these patterns only in production under realistic load.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"unknown-types","title":"Problem Domain: Unknown Concrete Types at Compile Time","content":[{"data":{"content":"A subtler but equally important motivation for the Prototype Pattern arises when **you cannot know the concrete type of objects at compile time**. This situation occurs frequently in plugin architectures, serialization systems, and user-customizable applications.\n\nConsider the challenge: You need to create new instances of objects, but the specific classes are:\n- Loaded dynamically at runtime\n- Defined by plugins or extensions\n- Determined by user configuration\n- Selected based on external input"},"type":"text"},{"data":{"content":"**The type-switching antipattern:**\n\nWithout cloning, handling unknown types typically devolves into explicit type-switching—checking the type of an existing object and manually constructing the corresponding concrete class:"},"type":"text"},{"data":{"fileName":"type-switching-antipattern.ts","languages":[{"code":"$7b","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"left":[{"data":{"items":["**Violates Open/Closed Principle** — Every new type requires modifying the copy function","**Cannot handle unknown types** — Plugins and extensions break this approach","**Exposes internal structure** — Must access all constructor parameters","**Error-prone** — Easy to miss a field when adding new types","**Maintenance nightmare** — Copy logic scattered across the codebase"],"title":{"icon":"XCircle","text":"Problems with Type-Switching","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Each type handles its own copying** — Self-contained clone logic","**Works with unknown types** — Objects copy themselves regardless of caller's knowledge","**Encapsulates internal structure** — Private fields stay private","**Guaranteed completeness** — Each class copies itself correctly","**Centralized copy logic** — Clone method lives with its class"],"title":{"icon":"CheckCircle","text":"Cloning Solves These Problems","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"}],"titleType":"number","titleNumber":3},{"id":"complex-configuration","title":"Problem Domain: Preserving Complex Configuration","content":[{"data":{"content":"Some objects reach their useful state through a complex sequence of configuration steps that involve multiple method calls, conditional setup, and interdependent options. These objects act as **runtime configurations**—templates that encode decisions made through user interaction, system defaults, and computed values.\n\nRecreating this configuration for each new instance would require duplicating the entire setup sequence—a wasteful and error-prone approach. Cloning offers a much more elegant solution: **capture the configuration once, replicate it freely**."},"type":"text"},{"data":{"fileName":"complex-configuration-problem.ts","languages":[{"code":"$7c","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"Prototypes as Templates","content":"When users create complex configurations interactively, those configurations become valuable artifacts. The Prototype Pattern transforms any configured object into a reusable template—allowing users to 'save' their setup and create variations without starting from scratch.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"subclass-explosion","title":"Problem Domain: Avoiding Subclass Explosion","content":[{"data":{"content":"Factory patterns typically require one factory or factory method for each concrete product type. When the number of product variations is large or grows dynamically, this leads to **subclass explosion**—a proliferation of factory classes that mirror the product hierarchy.\n\nThe Prototype Pattern offers an alternative: instead of subclassing factories, **register prototype instances and clone them on demand**. The registry holds one instance of each variation, and creating new objects becomes a matter of looking up and cloning the appropriate prototype."},"type":"text"},{"data":{"rows":[["For N product types:","N factory classes or methods","N prototype instances"],["Adding new type:","Create new factory class/method","Register new prototype instance"],["Runtime extensibility:","Difficult — requires code changes","Easy — just register new prototype"],["Memory overhead:","Minimal — factories are stateless","Higher — must keep prototype instances"],["Configuration flexibility:","Fixed at compile time","Can adjust prototype state at runtime"],["Plugin support:","Requires factory plugin interface","Plugins register their own prototypes"]],"caption":"Comparison: Factory Subclassing vs Prototype Registry","headers":["Aspect","Factory Subclasses","Prototype Registry"]},"type":"table"},{"data":{"fileName":"subclass-explosion-example.ts","languages":[{"code":"$7d","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"When Subclass Explosion Becomes Critical","content":"Subclass explosion is particularly painful in UI component libraries, document template systems, game entity frameworks, and any domain where variations multiply combinatorially. If you find yourself creating factory classes that differ only in which constructor they call, the Prototype Pattern may be a better fit.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"real-world-scenarios","title":"Real-World Scenarios Requiring Object Cloning","content":[{"data":{"content":"The problems we've discussed manifest across many real-world domains. Understanding where cloning naturally fits helps you recognize the pattern in your own work:"},"type":"text"},{"data":{"items":["**Graphics Editors** — Users create a shape, configure its properties (color, line width, shadow, effects), then duplicate it to create similar shapes. Cloning preserves all configuration without reimplementing the property-assignment workflow.","**Game Development** — Game entities (enemies, projectiles, power-ups) often spawn as variations of base prototypes. An 'archer enemy' prototype might be cloned 100 times per level, each clone maintaining the base configuration while allowing individual state changes.","**Configuration Management** — Environment configurations (dev, staging, production) share most settings but differ in specific values. Cloning a base configuration and modifying only the differences is cleaner than rebuilding each configuration from scratch.","**Document Processing** — Templates for invoices, reports, or contracts are prototypes that get cloned and filled with specific data. The template structure (formatting, sections, styles) is expensive to construct but free to clone.","**Caching and Pooling** — Object pools maintain pre-initialized prototypes that are cloned when objects are 'borrowed.' This avoids repeated initialization for frequently-requested object types.","**Undo/Redo Systems** — Saving object state for undo often involves cloning the object's state at each checkpoint. The pattern enables efficient state preservation without custom serialization logic.","**A/B Testing Frameworks** — Experiment configurations are created as variations of baseline prototypes. Cloning the baseline and adjusting specific parameters ensures consistent comparison conditions."],"title":{"icon":"Target","text":"Domain-Specific Applications","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":6},{"id":"pattern-recognition","title":"Recognizing the Prototype Pattern Opportunity","content":[{"data":{"content":"Pattern recognition is a critical skill for software design. Here are the key signals that suggest the Prototype Pattern may be appropriate for your situation:"},"type":"text"},{"data":{"type":"ordered","items":["**You're writing type-switching code to copy objects** — If you find yourself checking `instanceof` to determine how to copy an object, cloning would eliminate this branching.","**Object initialization is measurably expensive** — Profile your application. If object creation shows up in performance traces, especially for repeatedly-created objects, cloning may help.","**Users configure objects interactively** — When users spend effort configuring objects (through dialogs, wizards, or direct manipulation), those configurations should be preservable as prototypes.","**You need variations of a base configuration** — Creating many objects that differ only slightly from a common template is a classic prototype scenario.","**Factory hierarchies are exploding** — If your factory class count mirrors your product class count, prototypes may offer a simpler alternative.","**The system supports plugins or extensions** — When third-party code can define new types, prototypes allow creation without the core system knowing the concrete classes.","**You're implementing copy/paste functionality** — This is fundamentally object cloning. The Prototype Pattern provides the structured approach."],"title":"Signs You May Need the Prototype Pattern","variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"When NOT to Use Prototype","content":"The Prototype Pattern adds complexity. Don't use it when: (1) Object creation is already fast and simple, (2) Objects have complex circular references that make cloning difficult, (3) Objects hold external resources (file handles, connections) that shouldn't be duplicated, or (4) The 'deep vs shallow copy' question has no clear answer for your domain.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The Problem Space for Prototypes","content":[{"data":{"content":"We've explored the fundamental problems that motivate the Prototype Pattern—situations where traditional constructor-based object creation falls short:"},"type":"text"},{"data":{"type":"ordered","items":["**Expensive initialization becomes cumulative debt** — When creating many similar objects, repeated initialization costs compound. Cloning amortizes the setup cost across all copies.","**Type-switching is an antipattern** — Checking types to determine how to copy objects violates OOP principles and breaks extensibility. Cloning moves copy logic to where it belongs—in each class.","**Complex configurations deserve preservation** — Objects that reach their useful state through elaborate setup become templates worth cloning rather than recreating.","**Factory proliferation has limits** — When factory hierarchies parallel product hierarchies, prototype registries offer a flatter alternative.","**Runtime extensibility requires runtime solution** — Plugins and dynamic types can't be handled by compile-time factory methods. Prototypes work with types unknown at compile time."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand the problems that the Prototype Pattern addresses, we'll examine its solution in detail. The next page explores the **clone method**—the mechanism that enables objects to create copies of themselves. We'll examine interface design, implementation strategies, and the trade-offs between different cloning approaches."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the problem domain for the Prototype Pattern—when object cloning is preferable to traditional instantiation. Next, we'll explore how to implement the clone method that makes this pattern work.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_83eb629a9207a27d5b9cc6c407e4460b","title":"Solution: The Clone Method","order":1,"content":null,"isLocked":true},{"id":"seed_1dc4b6bfb2600b823c83eb95c7a8fa12","title":"Shallow vs Deep Copy","order":2,"content":null,"isLocked":true},{"id":"seed_47e720745b3453a7ae0e0d8abf5b95e3","title":"Registry of Prototypes","order":3,"content":null,"isLocked":true}]}}