6c:T40d,In introductory programming, object creation is taught as a syntactic necessity—you need objects, so you instantiate them. But at the architectural level, **how** you create objects shapes your entire system's design. **The fundamental tension:** Object-oriented design encourages programming to abstractions (interfaces, abstract classes) rather than concrete implementations. This principle—central to the Dependency Inversion Principle and the Open-Closed Principle—enables flexibility and extensibility. However, **the act of creation inherently requires knowing the concrete type**: ```java // Programming to abstraction PaymentProcessor processor = ...; // What goes here? // The problem: at some point, someone must say: PaymentProcessor processor = new StripePaymentProcessor(); // Concrete! ``` This creates a design dilemma: your code strives to be abstract and flexible, yet object creation ties it to specific concrete classes. Creational patterns exist precisely to **isolate and manage this necessary coupling**.6d:T6ba,// Abstract product interface interface Document { open(): void; save(): void; close(): void; } // Concrete products class PDFDocument implements Document { open(): void { console.log("Opening PDF document with PDF renderer"); } save(): void { console.log("Saving PDF with compression"); } close(): void { console.log("Closing PDF document"); } } class WordDocument implements Document { open(): void { console.log("Opening Word document with DOCX parser"); } save(): void { console.log("Saving Word document with formatting"); } close(): void { console.log("Closing Word document"); } } // Abstract creator with factory method abstract class Application { // Factory method - subclasses decide what to create protected abstract createDocument(): Document; // Template method that uses the factory method public newDocument(): Document { const doc = this.createDocument(); doc.open(); console.log("Document ready for editing"); return doc; } } // Concrete creators class PDFApplication extends Application { protected createDocument(): Document { return new PDFDocument(); } } class WordApplication extends Application { protected createDocument(): Document { return new WordDocument(); } } // Client code works with abstract types function clientCode(app: Application) { const document = app.newDocument(); document.save(); document.close(); } // Runtime selection of concrete application clientCode(new PDFApplication()); // Creates PDF documents clientCode(new WordApplication()); // Creates Word documents6e:Tbbb,// Abstract product interfaces for a UI component family interface Button { render(): void; onClick(handler: () => void): void; } interface Checkbox { render(): void; isChecked(): boolean; } interface TextInput { render(): void; getValue(): string; } // Abstract factory interface interface UIFactory { createButton(): Button; createCheckbox(): Checkbox; createTextInput(): TextInput; } // Windows family of products class WindowsButton implements Button { render(): void { console.log("Rendering Windows-style button"); } onClick(handler: () => void): void { /* Windows click handling */ } } class WindowsCheckbox implements Checkbox { render(): void { console.log("Rendering Windows-style checkbox"); } isChecked(): boolean { return false; } } class WindowsTextInput implements TextInput { render(): void { console.log("Rendering Windows-style text input"); } getValue(): string { return ""; } } // macOS family of products class MacOSButton implements Button { render(): void { console.log("Rendering macOS-style button"); } onClick(handler: () => void): void { /* macOS click handling */ } } class MacOSCheckbox implements Checkbox { render(): void { console.log("Rendering macOS-style checkbox"); } isChecked(): boolean { return false; } } class MacOSTextInput implements TextInput { render(): void { console.log("Rendering macOS-style text input"); } getValue(): string { return ""; } } // Concrete factories class WindowsUIFactory implements UIFactory { createButton(): Button { return new WindowsButton(); } createCheckbox(): Checkbox { return new WindowsCheckbox(); } createTextInput(): TextInput { return new WindowsTextInput(); } } class MacOSUIFactory implements UIFactory { createButton(): Button { return new MacOSButton(); } createCheckbox(): Checkbox { return new MacOSCheckbox(); } createTextInput(): TextInput { return new MacOSTextInput(); } } // Client code works only with abstract types class LoginForm { private button: Button; private rememberMe: Checkbox; private username: TextInput; private password: TextInput; constructor(factory: UIFactory) { // All components come from the same family this.button = factory.createButton(); this.rememberMe = factory.createCheckbox(); this.username = factory.createTextInput(); this.password = factory.createTextInput(); } render(): void { this.username.render(); this.password.render(); this.rememberMe.render(); this.button.render(); } } // Platform detection at application start function createUIFactory(): UIFactory { const platform = process.platform; if (platform === "darwin") { return new MacOSUIFactory(); } return new WindowsUIFactory(); } // Single decision point for entire object family const factory = createUIFactory(); const form = new LoginForm(factory); form.render();6f:Td30,// Complex product with many optional components class HttpRequest { readonly method: string; readonly url: string; readonly headers: Map; readonly body: string | null; readonly timeout: number; readonly retryCount: number; readonly followRedirects: boolean; readonly authentication: { type: string; credentials: string } | null; constructor( method: string, url: string, headers: Map, body: string | null, timeout: number, retryCount: number, followRedirects: boolean, authentication: { type: string; credentials: string } | null ) { this.method = method; this.url = url; this.headers = headers; this.body = body; this.timeout = timeout; this.retryCount = retryCount; this.followRedirects = followRedirects; this.authentication = authentication; } } // Fluent builder for step-by-step construction class HttpRequestBuilder { private method: string = "GET"; private url: string = ""; private headers: Map = new Map(); private body: string | null = null; private timeout: number = 30000; private retryCount: number = 0; private followRedirects: boolean = true; private auth: { type: string; credentials: string } | null = null; setMethod(method: "GET" | "POST" | "PUT" | "DELETE" | "PATCH"): this { this.method = method; return this; } setUrl(url: string): this { this.url = url; return this; } addHeader(name: string, value: string): this { this.headers.set(name, value); return this; } setJsonBody(data: object): this { this.body = JSON.stringify(data); this.headers.set("Content-Type", "application/json"); return this; } setTimeout(ms: number): this { this.timeout = ms; return this; } withRetry(count: number): this { this.retryCount = count; return this; } noFollowRedirects(): this { this.followRedirects = false; return this; } withBasicAuth(username: string, password: string): this { const credentials = btoa(`${username}:${password}`); this.auth = { type: "Basic", credentials }; this.headers.set("Authorization", `Basic ${credentials}`); return this; } withBearerToken(token: string): this { this.auth = { type: "Bearer", credentials: token }; this.headers.set("Authorization", `Bearer ${token}`); return this; } build(): HttpRequest { // Validation before construction if (!this.url) { throw new Error("URL is required"); } return new HttpRequest( this.method, this.url, new Map(this.headers), // Defensive copy this.body, this.timeout, this.retryCount, this.followRedirects, this.auth ); } } // Clean, readable construction const request = new HttpRequestBuilder() .setMethod("POST") .setUrl("https://api.example.com/users") .setJsonBody({ name: "Alice", role: "admin" }) .withBearerToken("eyJhbGciOiJIUzI1NiIs...") .withRetry(3) .setTimeout(5000) .build();70:Tb75,// Prototype interface interface Cloneable { clone(): T; } // Complex object that's expensive to create from scratch class GameCharacter implements Cloneable { name: string; health: number; level: number; equipment: Map; skills: Skill[]; position: { x: number; y: number }; // Expensive initialization private loadedAssets: string[] = []; constructor(name: string) { this.name = name; this.health = 100; this.level = 1; this.equipment = new Map(); this.skills = []; this.position = { x: 0, y: 0 }; // Simulating expensive asset loading this.loadAssets(); } private loadAssets(): void { // In reality, this might load textures, models, sounds... console.log(`Loading assets for ${this.name}...`); this.loadedAssets = ["texture", "model", "animations", "sounds"]; } // Deep clone implementation clone(): GameCharacter { // Create new instance without expensive asset loading const cloned = Object.create(GameCharacter.prototype); // Copy primitive values cloned.name = this.name; cloned.health = this.health; cloned.level = this.level; // Deep copy collections cloned.equipment = new Map( Array.from(this.equipment.entries()).map( ([slot, equip]) => [slot, equip.clone()] ) ); cloned.skills = this.skills.map(skill => skill.clone()); cloned.position = { ...this.position }; // Share expensive assets (they're read-only) cloned.loadedAssets = this.loadedAssets; return cloned; } } // Prototype registry for managing prototypes class CharacterPrototypeRegistry { private prototypes: Map = new Map(); register(key: string, prototype: GameCharacter): void { this.prototypes.set(key, prototype); } create(key: string): GameCharacter { const prototype = this.prototypes.get(key); if (!prototype) { throw new Error(`No prototype registered for: ${key}`); } return prototype.clone(); } } // Usage: create prototype templates once, clone many times const registry = new CharacterPrototypeRegistry(); // Expensive creation happens once per template const warriorTemplate = new GameCharacter("Warrior Template"); warriorTemplate.health = 150; warriorTemplate.skills.push(new MeleeSkill("Sword Strike")); warriorTemplate.equipment.set("weapon", new Sword("Iron Sword")); registry.register("warrior", warriorTemplate); // Fast cloning for spawning enemies const enemy1 = registry.create("warrior"); const enemy2 = registry.create("warrior"); enemy1.name = "Enemy Warrior 1"; enemy2.name = "Enemy Warrior 2"; // Assets loaded once, shared by all clones71:Ta08,// Classic Singleton implementation class ConfigurationManager { private static instance: ConfigurationManager | null = null; private settings: Map = new Map(); // Private constructor prevents external instantiation private constructor() { console.log("Loading configuration..."); this.loadFromEnvironment(); } // Controlled access point public static getInstance(): ConfigurationManager { if (!ConfigurationManager.instance) { ConfigurationManager.instance = new ConfigurationManager(); } return ConfigurationManager.instance; } private loadFromEnvironment(): void { // Load from environment, files, etc. this.settings.set("database.host", process.env.DB_HOST); this.settings.set("database.port", parseInt(process.env.DB_PORT || "5432")); this.settings.set("api.timeout", 30000); } get(key: string): T | undefined { return this.settings.get(key) as T | undefined; } // For testing: ability to reset (use with caution) public static resetInstance(): void { ConfigurationManager.instance = null; } } // Usage anywhere in application const config1 = ConfigurationManager.getInstance(); const config2 = ConfigurationManager.getInstance(); console.log(config1 === config2); // true - same instance // Thread-safe singleton (for environments with true concurrency) class ThreadSafeConnectionPool { private static instance: ThreadSafeConnectionPool | null = null; private static initializationLock = false; private connections: DatabaseConnection[] = []; private constructor(poolSize: number) { for (let i = 0; i < poolSize; i++) { this.connections.push(new DatabaseConnection()); } } public static getInstance(): ThreadSafeConnectionPool { // Double-checked locking pattern if (!ThreadSafeConnectionPool.instance) { if (!ThreadSafeConnectionPool.initializationLock) { ThreadSafeConnectionPool.initializationLock = true; try { if (!ThreadSafeConnectionPool.instance) { ThreadSafeConnectionPool.instance = new ThreadSafeConnectionPool(10); } } finally { ThreadSafeConnectionPool.initializationLock = false; } } } return ThreadSafeConnectionPool.instance!; } }65:{"json":{"id":"seed_e0b7d28bdd9d0f9bd6ac57bcbe2571eb","slug":"pattern-categories","category":"System Design (LLD)","topic":"Pattern Categories","title":"Pattern Categories: Creational, Structural, Behavioral","description":"Master the three fundamental categories of design patterns established by the Gang of Four. Understand how creational patterns manage object creation, structural patterns handle object composition, and behavioral patterns govern object interaction—and why this taxonomy accelerates pattern selection in real-world design.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_a7a37047f198d3910c113ae83aae5468","title":"Creational Patterns — Object Creation","order":0,"content":[{"id":"opening-context","title":"The Hidden Complexity of Object Creation","content":[{"data":{"content":"Every object-oriented system begins with a deceptively simple act: **creating objects**. A single line of code—`new Customer()` or `new PaymentProcessor()`—seems straightforward. Yet as systems grow in scale and complexity, this simplicity becomes a source of profound architectural challenges.\n\nConsider what happens when you need to:\n- Create objects whose concrete type isn't known until runtime\n- Construct complex objects with many optional configurations\n- Ensure only one instance of a critical resource exists\n- Build families of related objects that must work together\n- Hide the complexity of assembly from client code\n\nThese scenarios reveal that object creation is not merely a mechanical step—it's a **design decision** with far-reaching consequences for flexibility, testability, and maintainability."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"This page explores **Creational Design Patterns**—the first category in the Gang of Four's taxonomy. You'll understand why object creation deserves dedicated design attention, the problems creational patterns solve, and how each pattern in this category approaches instantiation differently. By the end, you'll recognize when object creation has become a design problem requiring a creational pattern solution.","variant":"info"},"type":"callout"}]},{"id":"why-creation-matters","title":"Why Object Creation Matters","content":[{"data":{"content":"$6c"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Instantiation Coupling Problem","content":"Every `new` keyword creates a compile-time dependency on a concrete class. If your business logic is littered with `new ConcreteClass()` calls, you've effectively hardwired your system to those implementations. Changing processors, storage mechanisms, or service providers requires modifying code throughout your application—violating the Open-Closed Principle.","variant":"warning"},"type":"callout"},{"data":{"content":"**The scope of creation complexity:**\n\nObject creation becomes architecturally significant when:\n\n1. **Type Selection is Dynamic** — The concrete type depends on runtime conditions (user input, configuration, context)\n\n2. **Construction is Complex** — Objects require multi-step assembly, dependencies, or validation before use\n\n3. **Instance Control is Required** — Only certain quantities of objects should exist (singletons, pools, flyweights)\n\n4. **Creation Varies by Context** — Different environments or platforms require different implementations\n\n5. **Object Families Must Coordinate** — Related objects must be created together to ensure compatibility\n\nCreational patterns provide principled solutions to each of these challenges, turning object creation from a scattered concern into a well-designed subsystem."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"creational-pattern-family","title":"The Creational Pattern Family","content":[{"data":{"content":"The Gang of Four identified **five fundamental creational patterns**, each addressing a specific aspect of object creation. These patterns share a common theme: **encapsulating knowledge about which concrete classes the system uses** while providing flexibility in what, how, and when objects get created."},"type":"text"},{"data":{"rows":[["**Factory Method**","Creating objects without specifying exact class","Delegate creation to subclasses via method override"],["**Abstract Factory**","Creating families of related objects","Interface for creating multiple related object types"],["**Builder**","Constructing complex objects step-by-step","Separate construction algorithm from representation"],["**Prototype**","Creating objects by cloning existing instances","Clone mechanism instead of constructor calls"],["**Singleton**","Ensuring exactly one instance exists","Private constructor with controlled access point"]],"caption":"The Five Classic Creational Patterns","headers":["Pattern","Primary Problem Solved","Key Mechanism"]},"type":"table"},{"data":{"content":"**What unifies creational patterns:**\n\n1. **Abstraction of Instantiation** — Client code works with interfaces, not concrete creation logic\n\n2. **Centralization of Knowledge** — Decisions about which classes to instantiate are localized, not scattered\n\n3. **Flexibility at Creation Time** — The system can adapt what it creates without changing how clients request creation\n\n4. **Encapsulation of Complexity** — Construction details are hidden from the code that uses objects\n\nEach pattern represents a different balance of these properties, optimized for different problem contexts."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"factory-method-pattern","title":"Factory Method Pattern","content":[{"data":{"content":"**The Problem:**\n\nYou're building a framework or library that defines a generic workflow, but specific steps require creating objects whose type varies based on the application's needs. You want to define the skeleton in a base class while allowing subclasses to determine which concrete objects to create.\n\n**The Solution:**\n\nThe Factory Method pattern defines an interface for creating an object but lets subclasses decide which class to instantiate. It defers instantiation to subclasses, allowing a class to delegate creation to its descendants."},"type":"text"},{"data":{"fileName":"factory-method-example.ts","languages":[{"code":"$6d","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"items":["**Eliminates coupling to concrete classes** — Client code depends only on the abstract `Document` interface","**Follows Open-Closed Principle** — Add new document types by creating new Application subclasses","**Encapsulates creation knowledge** — Each subclass knows how to create its specific product type","**Provides hooks for extension** — Subclasses customize creation logic without modifying framework code"],"title":{"icon":"CheckCircle","text":"Factory Method Benefits","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"When to Use Factory Method","content":"Use Factory Method when: (1) a class can't anticipate which objects it must create, (2) you want subclasses to specify what they create, or (3) you're building a framework where users override creation behavior. It's particularly common in frameworks where the core defines workflows but applications customize the objects involved.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"abstract-factory-pattern","title":"Abstract Factory Pattern","content":[{"data":{"content":"**The Problem:**\n\nYour system must create **families of related objects** that are designed to work together. Using objects from different families would cause errors or inconsistencies. You need a way to ensure that when you create a UI button, the scrollbar, checkbox, and window you create are all from the same UI toolkit (Windows, macOS, or Linux).\n\n**The Solution:**\n\nThe Abstract Factory pattern provides an interface for creating families of related objects without specifying their concrete classes. Each concrete factory produces a complete, compatible family of products."},"type":"text"},{"data":{"fileName":"abstract-factory-example.ts","languages":[{"code":"$6e","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**Abstract Factory vs. Factory Method:**\n\nThese patterns often work together but address different concerns:"},"type":"text"},{"data":{"rows":[["**Scope**","Creates **one product** type","Creates **families** of products"],["**Mechanism**","Inheritance (override method)","Composition (inject factory)"],["**Focus**","Defer creation to subclasses","Ensure product compatibility"],["**Variation**","One product varies","Multiple products vary together"]],"headers":["Aspect","Factory Method","Abstract Factory"]},"type":"table"},{"data":{"content":"In practice, Abstract Factories often use Factory Methods internally—each `create*` method is essentially a Factory Method."},"type":"text"},{"data":{"icon":"Info","title":"Real-World Applications","content":"Abstract Factory is essential in: (1) Cross-platform UI frameworks ensuring visual consistency, (2) Database access layers supporting multiple database engines, (3) Document processing systems handling different file formats, (4) Game engines creating themed entity families. Anywhere you need guaranteed compatibility between related objects, Abstract Factory applies.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"builder-pattern","title":"Builder Pattern","content":[{"data":{"content":"**The Problem:**\n\nYou need to create complex objects with many optional components and possible configurations. Using constructors leads to either:\n- **Telescoping constructors** — Dozens of constructor overloads with different parameter combinations\n- **Null parameters** — Long parameter lists where most arguments are `null`\n- **Mutable construction** — Creating an incomplete object and setting properties afterward (risky)\n\n**The Solution:**\n\nThe Builder pattern separates the construction of a complex object from its representation. A Builder constructs the product step-by-step, allowing different representations to be created using the same construction process."},"type":"text"},{"data":{"fileName":"builder-pattern-example.ts","languages":[{"code":"$6f","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"left":[{"data":{"items":["**Readable code** — Method names document what each parameter means","**Immutable products** — Built objects can be fully immutable","**Validation** — Builder can validate before construction","**Optional complexity** — Only specify what you need"],"title":{"icon":"CheckCircle","text":"Builder Advantages","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Objects with many optional parameters","Need for immutable products","Same process creates different representations","Construction requires validation"],"title":{"icon":"AlertCircle","text":"When to Choose Builder","type":"icon","color":"accent","variant":"outline-circle"},"variant":"glass"},"type":"list"}]},"type":"two-column"}],"titleType":"number","titleNumber":5},{"id":"prototype-pattern","title":"Prototype Pattern","content":[{"data":{"content":"**The Problem:**\n\nYou need to create new objects that are similar to existing objects, but:\n- The object's class may not be known to your code (you only have a reference)\n- Creating from scratch is expensive (database fetches, complex calculations)\n- You want to avoid a complex class hierarchy of factories\n\n**The Solution:**\n\nThe Prototype pattern creates new objects by copying (cloning) an existing object—the prototype. This delegates creation to the objects themselves, avoiding the need to know their concrete classes."},"type":"text"},{"data":{"fileName":"prototype-pattern-example.ts","languages":[{"code":"$70","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Shallow vs. Deep Cloning","content":"The biggest challenge with Prototype is implementing cloning correctly. **Shallow copy** duplicates only top-level values—nested objects remain shared. **Deep copy** recursively clones all nested structures. Choose based on your needs: shared references for read-only data, deep copies for independently mutable state. Circular references require special handling to avoid infinite loops.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"singleton-pattern","title":"Singleton Pattern","content":[{"data":{"content":"**The Problem:**\n\nCertain resources must have exactly one instance throughout the application's lifetime:\n- Database connection pools\n- Application configuration\n- Logging services\n- Hardware interface managers\n\nMultiple instances could cause resource conflicts, inconsistent state, or excessive resource consumption.\n\n**The Solution:**\n\nThe Singleton pattern ensures a class has only one instance and provides a global point of access to it. The class itself manages its single instance, preventing external code from creating additional instances."},"type":"text"},{"data":{"fileName":"singleton-pattern-example.ts","languages":[{"code":"$71","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Singleton Controversies","content":"Singleton is often criticized as an anti-pattern because: (1) Global state makes testing difficult—you can't easily substitute mock instances. (2) Hidden dependencies—classes using singletons have non-obvious dependencies. (3) Concurrency complexity—thread-safe initialization is tricky. Consider **Dependency Injection** as an alternative: inject a single instance rather than having classes fetch it globally. This preserves single-instance semantics while enabling testability.","variant":"error"},"type":"callout"},{"data":{"content":"**Modern alternatives to traditional Singleton:**\n\n1. **Module-level instance** (JavaScript/TypeScript) — Export a single instance from a module\n```typescript\n// config.ts\nclass ConfigurationManager { /* ... */ }\nexport const config = new ConfigurationManager();\n// Other files import the same instance\n```\n\n2. **Dependency Injection container** — Let the DI framework manage instance lifetime\n```typescript\n// Register as singleton in container\ncontainer.register(ConfigurationManager, { lifecycle: Lifecycle.Singleton });\n```\n\n3. **Service locator with replaceable implementation** — Global access but swappable for testing\n\nThese approaches maintain single-instance behavior while improving testability and reducing global state issues."},"type":"text"}],"titleType":"number","titleNumber":7},{"id":"choosing-creational-pattern","title":"Choosing the Right Creational Pattern","content":[{"data":{"content":"Selecting the appropriate creational pattern begins with understanding your specific creation challenge. Each pattern optimizes for different scenarios:"},"type":"text"},{"data":{"rows":[["Unknown concrete type at compile time","**Factory Method**","Subclasses should decide what to create"],["Need families of compatible objects","**Abstract Factory**","Products must be used together consistently"],["Complex object with many configurations","**Builder**","Telescoping constructors, many optional parts"],["Creating expensive-to-initialize objects","**Prototype**","Clone from template faster than construct new"],["Must have exactly one instance","**Singleton**","Global access point, shared resource"]],"caption":"Creational Pattern Selection Guide","headers":["If Your Problem Is...","Consider...","Key Indicator"]},"type":"table"},{"data":{"type":"ordered","items":["**How many product types?** — One type suggests Factory Method; multiple related types suggest Abstract Factory","**Is construction complex?** — Many optional parameters or multi-step construction suggests Builder","**Is initialization expensive?** — If so, Prototype can amortize the cost across clones","**Is instance count controlled?** — Exactly one instance suggests Singleton (or DI-managed singleton)","**Who should decide the concrete type?** — Framework defines it: Factory Method. Client selects family: Abstract Factory"],"title":{"icon":"Target","text":"Decision Process Questions","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Patterns Combine Naturally","content":"Creational patterns often work together. An Abstract Factory might use Factory Methods internally. A Builder might use a Prototype for its default state. A Factory might return a Singleton for certain types. Don't think of patterns as mutually exclusive—they're complementary tools addressing different aspects of creation.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":8},{"id":"summary","title":"Summary: Creational Patterns","content":[{"data":{"content":"Creational patterns address the first fundamental challenge in object-oriented design: **how do we create objects flexibly and maintainably?** By encapsulating creation logic, these patterns decouple systems from the concrete classes they instantiate, enabling the flexibility that SOLID principles demand."},"type":"text"},{"data":{"type":"ordered","items":["**Object creation is a design concern** — Where and how you instantiate objects affects flexibility, testability, and maintainability","**Factory Method** delegates creation to subclasses, enabling framework extension without modification","**Abstract Factory** ensures families of related objects are created consistently and compatibly","**Builder** separates complex construction from representation, enabling readable, validated object creation","**Prototype** creates objects by cloning, avoiding expensive initialization and unknown concrete types","**Singleton** controls instance count but should be used judiciously due to testability concerns","**Patterns complement each other** — Real systems often combine multiple creational patterns"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Sparkles","title":"Looking Ahead","content":"You now understand **Creational Patterns**—the first category of the Gang of Four taxonomy. Next, we'll explore **Structural Patterns**, which address how objects and classes combine to form larger structures. Where creational patterns manage *what* gets created, structural patterns manage *how* things connect.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":9}],"isLocked":false},{"id":"seed_484c809897284d278e4686fdcefffed1","title":"Structural Patterns — Object Composition","order":1,"content":null,"isLocked":true},{"id":"seed_786f2905e70eaf9b06469f614723ca9e","title":"Behavioral Patterns — Object Interaction","order":2,"content":null,"isLocked":true},{"id":"seed_f1b728bc6f1a14752cb38b3b9791b0d3","title":"Categorization Purpose — Why the Taxonomy Matters","order":3,"content":null,"isLocked":true}]}}