7a:T4f2,**Interfaces as Abstraction Boundaries:** Interfaces exist at each level where we need to establish a stable contract between layers. They are not just a programming construct—they are *architectural boundaries* that define how components interact. Consider what happens without proper abstraction boundaries. If module A directly uses the concrete class from module B, any change to B's implementation potentially breaks A. This creates a rigid system where changes propagate unpredictably. Interfaces break this chain of dependency by establishing a stable contract that both modules agree upon. **The Essence of Interface-Based Abstraction:** An interface represents a *role* that implementations fulfill. When you define an interface, you're not describing a thing—you're describing a capability. This is a crucial distinction: - A `DatabaseConnection` describes a thing (a connection to a database) - A `DataStore` describes a capability (the ability to store and retrieve data) The capability-focused view is more powerful because it allows any implementation that provides that capability, regardless of its nature. A `DataStore` could be a database, a file system, an in-memory cache, or a remote API—the client code doesn't need to know or care.7b:T4aa,// A well-designed interface demonstrates the abstraction of "message sending" // Note: We define WHAT operations exist, not HOW they work interface MessageSender { // Method signature: defines contract for sending messages send(recipient: string, message: string): Promise; // Method signature: defines contract for checking send status getStatus(messageId: string): Promise; // Method signature: batch operations for efficiency sendBatch(messages: Message[]): Promise; // Property: read-only capability indicator readonly supportsRichContent: boolean; } // The interface makes NO assumptions about: // - Whether this uses email, SMS, push notifications, or carrier pigeon // - What network protocols are involved // - How retries are handled // - Where messages are queued // - What happens during failures // Each of these could be radically different implementations: class EmailSender implements MessageSender { /* ... */ } class SMSSender implements MessageSender { /* ... */ } class SlackSender implements MessageSender { /* ... */ } class MockSender implements MessageSender { /* for testing */ }7c:T499,**The Semantic Elements:** Beyond syntax, interfaces carry implicit semantic meaning that is equally important: 1. **Preconditions** — What must be true before a method is called (e.g., recipient must be valid). 2. **Postconditions** — What will be true after a method completes (e.g., message will be queued). 3. **Invariants** — What must always be true for any implementation (e.g., sent messages cannot be unsent). 4. **Error Conditions** — How failures are communicated (exceptions, error codes, null returns). 5. **Behavioral Expectations** — Implied behaviors like idempotency, thread safety, or eventual consistency. These semantic elements form the *contract* of the interface. Syntactic compliance is verified by the compiler; semantic compliance must be maintained through discipline, documentation, and testing. **The Implicit Protocol:** Every interface implies a protocol—an expected sequence of interactions. For example, a `Connection` interface implies: open → use → close. A `Transaction` interface implies: begin → operate → commit/rollback. These protocols are part of the interface's contract even if not expressible in syntax.7d:T7f3,// Step 1: Define the public contract as an interface interface PaymentProcessor { processPayment(payment: PaymentRequest): Promise; refund(transactionId: string, amount: Money): Promise; getTransactionHistory(query: TransactionQuery): Promise; } // Step 2: Provide an abstract base class with common functionality abstract class BasePaymentProcessor implements PaymentProcessor { // Shared state protected readonly logger: Logger; protected readonly auditService: AuditService; constructor(logger: Logger, auditService: AuditService) { this.logger = logger; this.auditService = auditService; } // Template method pattern: defines the algorithm skeleton async processPayment(payment: PaymentRequest): Promise { this.logger.info('Processing payment', { payment }); await this.validatePayment(payment); // Abstract - must implement const result = await this.executePayment(payment); // Abstract - must implement await this.auditService.record(payment, result); // Shared return result; } // Abstract methods that subclasses must implement protected abstract validatePayment(payment: PaymentRequest): Promise; protected abstract executePayment(payment: PaymentRequest): Promise; // Other interface methods... abstract refund(transactionId: string, amount: Money): Promise; abstract getTransactionHistory(query: TransactionQuery): Promise; } // Step 3: Implementations can extend base class or implement interface directly class StripePaymentProcessor extends BasePaymentProcessor { // Inherits logging, auditing, and algorithm structure // Only needs to provide Stripe-specific logic } class CustomPaymentProcessor implements PaymentProcessor { // Complete freedom - doesn't use the base class at all // Useful when the base class abstractions don't fit }7e:T488,// ❌ PROBLEMATIC: Direct dependency on concrete implementation class GmailEmailService { constructor(private apiKey: string, private sender: string) {} sendEmail(to: string, subject: string, body: string): void { // Gmail-specific implementation // Uses Gmail API, handles Gmail-specific authentication } } class ReportGenerator { private emailService: GmailEmailService; // ← Direct dependency on Gmail constructor() { // Hard-coded dependency creation this.emailService = new GmailEmailService('key123', 'reports@company.com'); } generateAndSendReport(reportData: ReportData): void { const report = this.buildReport(reportData); this.emailService.sendEmail( reportData.recipient, 'Your Report', report ); } } // Problems with this design: // 1. ReportGenerator is coupled to Gmail specifically // 2. Cannot test without Gmail credentials and network // 3. Cannot switch to different email provider // 4. Cannot use for non-email delivery (Slack, SMS) // 5. Changes to GmailEmailService ripple to ReportGenerator7f:T86c,// ✅ CORRECT: Dependency on abstraction // The interface lives with the high-level module (ReportGenerator) // This is crucial - the abstraction is owned by the consumer interface NotificationSender { send(recipient: string, subject: string, content: string): Promise; } // High-level module depends only on the interface class ReportGenerator { constructor(private notificationSender: NotificationSender) {} async generateAndSendReport(reportData: ReportData): Promise { const report = this.buildReport(reportData); await this.notificationSender.send( reportData.recipient, 'Your Report', report ); } // ReportGenerator has zero knowledge of: // - Email, SMS, Slack, or any specific transport // - Network protocols or authentication // - Retry logic or failure handling // - Provider-specific quirks } // Low-level modules implement the interface class GmailSender implements NotificationSender { constructor(private apiKey: string, private sender: string) {} async send(recipient: string, subject: string, content: string): Promise { // Gmail-specific implementation } } class SendGridSender implements NotificationSender { async send(recipient: string, subject: string, content: string): Promise { // SendGrid-specific implementation } } class SlackSender implements NotificationSender { async send(recipient: string, subject: string, content: string): Promise { // Slack-specific implementation (recipient = channel) } } class MockSender implements NotificationSender { public sentMessages: Array<{recipient: string; subject: string; content: string}> = []; async send(recipient: string, subject: string, content: string): Promise { this.sentMessages.push({ recipient, subject, content }); } } // Dependency injection makes everything flexible const prodReportGenerator = new ReportGenerator(new GmailSender(config.gmail.apiKey, config.gmail.sender)); const testReportGenerator = new ReportGenerator(new MockSender());80:T427,Designing effective interfaces requires more than just extracting method signatures from classes. A well-designed interface embodies principles that maximize its value as an abstraction. **Principle 1: Interface Segregation** Interfaces should be small and focused. The Interface Segregation Principle (ISP) states that clients should not be forced to depend on methods they don't use. A "fat" interface that covers many responsibilities forces implementers to provide methods irrelevant to their purpose. **Principle 2: Conceptual Unity** All methods in an interface should belong to one coherent concept. If you find yourself naming an interface `UserManagerAndEmailSender`, you've violated conceptual unity. Split it into focused interfaces. **Principle 3: Consumer-Driven Design** Design interfaces from the perspective of the consumer, not the implementer. Ask "What operations does the consumer need?" rather than "What can this implementation do?" This ensures the interface serves its clients rather than merely exposing implementation capabilities.81:T63e,// ❌ POOR: Fat interface mixing concerns interface UserService { createUser(data: UserData): Promise; updateUser(id: string, data: UserData): Promise; deleteUser(id: string): Promise; getUserById(id: string): Promise; getUsersByRole(role: string): Promise; sendWelcomeEmail(user: User): Promise; sendPasswordResetEmail(user: User): Promise; validatePassword(password: string): boolean; hashPassword(password: string): string; authenticate(email: string, password: string): Promise; generateAuthToken(user: User): string; invalidateAuthToken(token: string): void; } // ✅ GOOD: Segregated interfaces with single responsibilities interface UserRepository { create(data: UserData): Promise; update(id: string, data: UserData): Promise; delete(id: string): Promise; findById(id: string): Promise; findByRole(role: string): Promise; } interface UserNotifier { sendWelcomeEmail(user: User): Promise; sendPasswordResetEmail(user: User): Promise; } interface PasswordService { validate(password: string): ValidationResult; hash(password: string): string; verify(password: string, hash: string): boolean; } interface AuthenticationService { authenticate(email: string, password: string): Promise; generateToken(user: User): string; invalidateToken(token: string): void; } // Each interface can now be implemented and tested independently // Consumers depend only on what they need82:T43e,**Principle 4: Semantic Clarity** Interface names and method signatures should clearly communicate their purpose. Avoid generic names that don't convey meaning (`doProcess`, `handleStuff`). Use domain language that makes the interface self-documenting. **Principle 5: Minimal Coupling in Parameters** Avoid using concrete types in interface method parameters when primitives or other interfaces suffice. Each concrete type in a signature creates a dependency that reduces flexibility. **Principle 6: Appropriate Abstraction Level** Interfaces should operate at the abstraction level appropriate for their consumers. A business logic consumer shouldn't deal with database transactions; a UI consumer shouldn't deal with HTTP headers. Match the interface to its usage context. **Principle 7: Stability Through Careful Design** Once published, interfaces are expensive to change. Every change potentially breaks all implementers. Design interfaces thoughtfully, considering future needs, before committing them. Adding methods is usually safe; changing or removing them is breaking.83:Td40,// =============================================== // INTERFACES - Owned by the domain/core layer // =============================================== interface InventoryChecker { checkAvailability(items: OrderItem[]): Promise; reserve(items: OrderItem[], orderId: OrderId): Promise; release(orderId: OrderId): Promise; } interface PaymentProcessor { charge(order: Order, paymentMethod: PaymentMethod): Promise; refund(chargeId: ChargeId, amount: Money): Promise; } interface OrderRepository { save(order: Order): Promise; findById(id: OrderId): Promise; updateStatus(id: OrderId, status: OrderStatus): Promise; } interface CustomerNotifier { notifyOrderConfirmation(order: Order): Promise; notifyOrderShipped(order: Order, tracking: TrackingInfo): Promise; notifyOrderCancelled(order: Order, reason: string): Promise; } interface AnalyticsTracker { trackOrderCreated(order: Order): void; trackOrderFulfilled(order: Order): void; trackRevenueRecorded(amount: Money): void; } // =============================================== // DOMAIN SERVICE - Depends only on interfaces // =============================================== class OrderProcessor { constructor( private inventoryChecker: InventoryChecker, private paymentProcessor: PaymentProcessor, private orderRepository: OrderRepository, private customerNotifier: CustomerNotifier, private analyticsTracker: AnalyticsTracker, ) {} async processOrder(orderRequest: OrderRequest): Promise { // 1. Check inventory const availability = await this.inventoryChecker.checkAvailability(orderRequest.items); if (!availability.allAvailable) { return OrderResult.failed('Items not available', availability.unavailable); } // 2. Reserve inventory const reservation = await this.inventoryChecker.reserve( orderRequest.items, orderRequest.orderId ); try { // 3. Process payment const order = Order.create(orderRequest); const chargeResult = await this.paymentProcessor.charge( order, orderRequest.paymentMethod ); if (!chargeResult.success) { await this.inventoryChecker.release(orderRequest.orderId); return OrderResult.failed('Payment failed', chargeResult.error); } // 4. Persist order order.markAsPaid(chargeResult.chargeId); await this.orderRepository.save(order); // 5. Notify customer (fire and forget) this.customerNotifier.notifyOrderConfirmation(order).catch(console.error); // 6. Track analytics (fire and forget) this.analyticsTracker.trackOrderCreated(order); this.analyticsTracker.trackRevenueRecorded(order.total); return OrderResult.success(order); } catch (error) { // Compensating transaction: release inventory await this.inventoryChecker.release(orderRequest.orderId); throw error; } } }84:T533,describe('OrderProcessor', () => { let processor: OrderProcessor; let mockInventory: jest.Mocked; let mockPayment: jest.Mocked; let mockRepository: jest.Mocked; let mockNotifier: jest.Mocked; let mockAnalytics: jest.Mocked; beforeEach(() => { mockInventory = createMockInventory(); mockPayment = createMockPayment(); mockRepository = createMockRepository(); mockNotifier = createMockNotifier(); mockAnalytics = createMockAnalytics(); processor = new OrderProcessor( mockInventory, mockPayment, mockRepository, mockNotifier, mockAnalytics, ); }); it('should release inventory when payment fails', async () => { mockInventory.checkAvailability.mockResolvedValue({ allAvailable: true }); mockInventory.reserve.mockResolvedValue({ success: true }); mockPayment.charge.mockResolvedValue({ success: false, error: 'Declined' }); const result = await processor.processOrder(createTestOrder()); expect(result.success).toBe(false); expect(mockInventory.release).toHaveBeenCalledWith(expect.any(String)); }); });72:{"json":{"id":"seed_fead067c8e00d562467e627e84169eff","slug":"depending-on-abstractions","category":"System Design (HLD)","topic":"Depending on Abstractions","title":"Depending on Abstractions","description":"Master the art of designing systems that depend on abstractions rather than concrete implementations. Learn how interfaces serve as the cornerstone of flexible, testable, and maintainable architectures, enabling true dependency inversion and creating systems that gracefully evolve over time.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_3bef477e310b108cdbfebf8cbbc0f7c5","title":"Interfaces as Abstraction","order":0,"content":[{"id":"opening-hook","title":"The Architecture of Independence","content":[{"data":{"content":"In the annals of software engineering, few concepts have proven as transformative as the interface. What appears on the surface to be a simple language feature—a collection of method signatures without implementation—is in reality the most powerful abstraction mechanism ever devised for building large-scale software systems.\n\nInterfaces represent a fundamental philosophical shift in how we think about software. Instead of asking \"What does this object do?\" we ask \"What contract does this object fulfill?\" This subtle reframing enables architectural patterns that would be impossible in a world of concrete dependencies.\n\nAt their core, interfaces answer a profound question: **How do we build systems where components can be developed, tested, and replaced independently?** The answer lies in understanding interfaces not as a programming convenience, but as the primary mechanism for achieving architectural freedom."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Master","content":"By the end of this page, you will understand interfaces as architectural tools, not just language features. You'll learn how interfaces create abstraction layers that enable dependency inversion, facilitate testing, and provide the flexibility to swap implementations without cascading changes. You'll see why experienced architects consider interfaces the single most important tool in their design arsenal.","variant":"info"},"type":"callout"}]},{"id":"nature-of-abstraction","title":"The Nature of Abstraction","content":[{"data":{"content":"Before we can fully appreciate interfaces, we must understand what abstraction truly means in software engineering. Abstraction is not simply \"hiding details\"—it is the deliberate creation of a conceptual boundary that separates *what* something does from *how* it does it.\n\n**The Philosophical Foundation:**\n\nPlato's allegory of the cave provides a useful metaphor. In Plato's cave, prisoners see only shadows on the wall—abstractions of real objects. These shadows lack detail, but they convey essential information about shape and movement. Similarly, an interface is a shadow of an implementation: it reveals the essential behavior while concealing the mechanical details.\n\nThe power of abstraction lies in this selective revelation. When you depend on an interface, you depend only on what matters for your purposes—the contract—while remaining blissfully ignorant of implementation specifics that could change.\n\n**Levels of Abstraction:**\n\nSoftware systems operate at multiple abstraction levels simultaneously:"},"type":"text"},{"data":{"rows":[["Hardware","Memory addresses","Physical RAM chips","Electrical signals, timing"],["Operating System","Files and processes","Disk sectors, CPU scheduling","Device drivers, interrupts"],["Language Runtime","Objects and methods","Memory allocation, garbage collection","Pointer arithmetic, heap management"],["Framework","Services and repositories","HTTP handlers, SQL queries","Protocol details, connection pooling"],["Application","Business operations","Framework components","Technical infrastructure"]],"caption":"Abstraction Levels in Software Systems","headers":["Level","Abstraction","Concrete Reality","What's Hidden"]},"type":"table"},{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Abstraction Test","content":"To evaluate whether an interface represents a good abstraction, ask: 'Could this interface be implemented in fundamentally different ways?' If the answer is yes, you have a genuine abstraction. If the interface is so specific that only one implementation is possible, it's just a thin wrapper around the concrete class—not a true abstraction.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"anatomy-of-interface","title":"Anatomy of an Interface","content":[{"data":{"content":"An interface is deceptively simple in its syntactic form, but understanding its components reveals the depth of the abstraction mechanism.\n\n**The Syntactic Elements:**\n\nIn most object-oriented languages, an interface consists of:\n\n1. **Method Signatures** — The operations that implementing classes must provide, including method names, parameter types, and return types.\n\n2. **Properties (in some languages)** — Gettable and/or settable values that implementations must expose.\n\n3. **Constants (in some languages)** — Immutable values associated with the interface.\n\n4. **Type Information** — The interface name itself becomes a type that can be used in declarations, parameters, and return types.\n\nNotably absent is any implementation. This is not an oversight—it's the entire point. The interface defines *what* while implementations define *how*."},"type":"text"},{"data":{"code":"$7b","fileName":"interface_anatomy.ts","language":"typescript"},"type":"code"},{"data":{"content":"$7c"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Contract Is More Than Syntax","content":"The most common interface design mistake is focusing only on syntax while ignoring semantics. An interface can be syntactically satisfied while completely violating its intended contract. For instance, a `Cache` interface implementation that never actually caches anything is syntactically correct but semantically broken. Document the full contract, not just the method signatures.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"interfaces-vs-abstract-classes","title":"Interfaces vs Abstract Classes","content":[{"data":{"content":"A perpetual question in object-oriented design is when to use interfaces versus abstract classes. Understanding the fundamental differences illuminates when each is appropriate.\n\n**The Core Distinction:**\n\n- **Interface** = \"can behave as\" (capability/role)\n- **Abstract Class** = \"is a kind of\" (identity/category)\n\nThis distinction seems subtle but has profound implications. An interface says \"I promise to provide these behaviors.\" An abstract class says \"I am a specialized version of this thing.\"\n\n**The Inheritance Model:**\n\nMost languages allow a class to implement multiple interfaces but inherit from only one abstract class (single inheritance). This isn't an arbitrary limitation—it reflects the conceptual difference:\n\n- A thing can have many capabilities (multiple interfaces)\n- A thing can only be one kind of thing (single inheritance)\n\nA `Document` class might implement `Printable`, `Exportable`, `Searchable`, and `Versionable` interfaces while extending a single `PersistentEntity` abstract class."},"type":"text"},{"data":{"left":[{"data":{"items":["**Pure contract** — No implementation provided","**Multiple inheritance** — A class can implement many interfaces","**No state** — Cannot declare instance fields","**Weak coupling** — Only behavioral dependency","**Role-based** — Describes what something can do","**Compositional** — Promotes composition over inheritance"],"title":{"icon":"FileCode","text":"Interface Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Partial implementation** — Can provide default behavior","**Single inheritance** — A class can extend one abstract class","**Has state** — Can declare instance fields","**Stronger coupling** — Inheritance binds more tightly","**Identity-based** — Describes what something is","**Hierarchical** — Promotes inheritance hierarchies"],"title":{"icon":"Code","text":"Abstract Class Characteristics","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**When to Choose Interface:**\n\n- When defining a role that unrelated classes might fulfill\n- When you want maximum flexibility for implementers\n- When the contract is purely behavioral with no shared state\n- When you anticipate multiple, independent implementations\n- When dependency inversion is a primary goal\n\n**When to Choose Abstract Class:**\n\n- When there's genuinely shared implementation among subclasses\n- When you want to provide sensible defaults that can be overridden\n- When the abstraction requires shared state\n- When you're defining a family of closely related types\n- When template method or similar patterns apply\n\n**The Hybrid Approach:**\n\nA powerful pattern combines both: define an interface for the public contract, then provide an abstract base class implementing common functionality. Clients depend on the interface (maximum flexibility), while implementers can choose to extend the base class (convenience) or implement the interface directly (maximum control)."},"type":"text"},{"data":{"code":"$7d","fileName":"hybrid_approach.ts","language":"typescript"},"type":"code"},{"data":{"icon":"Info","title":"The Preference for Interfaces","content":"In dependency inversion contexts, prefer interfaces over abstract classes. Interfaces provide maximum decoupling because they carry no implementation baggage. When a client depends on an interface, it depends only on the contract—not on any base class implementation details, default behaviors, or protected methods that abstract classes might expose.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"dependency-boundaries","title":"Interfaces as Dependency Boundaries","content":[{"data":{"content":"The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules; both should depend on abstractions. Interfaces are the mechanism by which this inversion is achieved.\n\n**The Traditional Dependency Problem:**\n\nConsider a typical application without DIP. A `ReportGenerator` class needs to send reports via email. The naive approach creates a direct dependency:"},"type":"text"},{"data":{"code":"$7e","fileName":"traditional_dependency.ts","language":"typescript"},"type":"code"},{"data":{"content":"**The Interface-Based Solution:**\n\nBy introducing an interface, we create a stable boundary between the high-level policy (report generation) and the low-level mechanism (email sending):"},"type":"text"},{"data":{"code":"$7f","fileName":"interface_based_solution.ts","language":"typescript"},"type":"code"},{"data":{"content":"**The Inversion Explained:**\n\nNotice what changed:\n\n1. **Before Inversion:** `ReportGenerator` (high-level) → `GmailEmailService` (low-level)\n - High-level depends on low-level details\n\n2. **After Inversion:** `ReportGenerator` (high-level) → `NotificationSender` (interface) ← `GmailSender` (low-level)\n - Both depend on the abstraction\n - The low-level module's arrow is reversed (it now implements the interface)\n - Dependencies flow toward abstractions\n\nThis is the \"inversion\"—we've inverted the direction of the dependency from low-level to high-level, replacing it with dependencies from both directions toward a shared abstraction.\n\n**Benefits of the Interface Boundary:**"},"type":"text"},{"data":{"items":["**Isolation** — Changes to email provider implementation don't affect ReportGenerator","**Testability** — MockSender enables fast, isolated unit tests","**Flexibility** — Swap providers without changing business logic","**Extensibility** — Add new notification channels without modification","**Parallel Development** — Teams can work independently on each side of the interface","**Deployment Independence** — Different implementations can be deployed separately"],"title":{"icon":"CheckCircle","text":"Interface Boundary Benefits","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"The Direction of Dependencies Matters","content":"In a well-designed system, dependencies point toward stability. Interfaces (abstractions) are more stable than implementations because they change less frequently. By making both high-level and low-level modules depend on interfaces, you create a system where the most stable elements (abstractions) are at the center, and volatility is pushed to the edges (implementations).","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"interface-design-principles","title":"Interface Design Principles","content":[{"data":{"content":"$80"},"type":"text"},{"data":{"code":"$81","fileName":"interface_design_examples.ts","language":"typescript"},"type":"code"},{"data":{"content":"$82"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Interface Stability Imperative","content":"Treat published interfaces as contracts. In distributed systems or public APIs, interface changes can break integrations you don't control. Prefer introducing new interfaces or new methods over modifying existing ones. When changes are unavoidable, use versioning strategies (IUserServiceV2) or deprecation cycles.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"common-interface-patterns","title":"Common Interface Patterns","content":[{"data":{"content":"Certain interface patterns appear repeatedly across software systems. Understanding these patterns helps you recognize opportunities to apply abstraction effectively.\n\n**Pattern 1: Repository Pattern**\n\nAbstracts data persistence, allowing business logic to work with domain objects without knowledge of storage mechanisms."},"type":"text"},{"data":{"code":"interface OrderRepository {\n save(order: Order): Promise;\n findById(id: OrderId): Promise;\n findByCustomer(customerId: CustomerId): Promise;\n findPending(): Promise;\n delete(id: OrderId): Promise;\n}\n\n// Can be implemented by:\n// - PostgresOrderRepository (SQL)\n// - MongoOrderRepository (NoSQL)\n// - InMemoryOrderRepository (testing)\n// - CachedOrderRepository (decorator adding caching)","fileName":"repository_pattern.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Pattern 2: Service Interface**\n\nDefines business operations at a higher abstraction level than repositories, often coordinating multiple resources."},"type":"text"},{"data":{"code":"interface PaymentService {\n processPayment(order: Order, paymentMethod: PaymentMethod): Promise;\n initiateRefund(orderId: OrderId, amount: Money): Promise;\n getPaymentStatus(paymentId: PaymentId): Promise;\n}\n\n// Hides complexity of:\n// - Payment gateway selection\n// - Fraud detection\n// - Currency conversion\n// - Retry logic","fileName":"service_interface.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Pattern 3: Strategy Interface**\n\nDefines a family of interchangeable algorithms or policies."},"type":"text"},{"data":{"code":"interface PricingStrategy {\n calculatePrice(product: Product, customer: Customer): Money;\n}\n\nclass StandardPricing implements PricingStrategy { /* ... */ }\nclass VIPDiscountPricing implements PricingStrategy { /* ... */ }\nclass PromotionalPricing implements PricingStrategy { /* ... */ }\nclass RegionalPricing implements PricingStrategy { /* ... */ }","fileName":"strategy_interface.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Pattern 4: Observer/Listener Interface**\n\nDefines the callback contract for event handling."},"type":"text"},{"data":{"code":"interface OrderEventListener {\n onOrderCreated(event: OrderCreatedEvent): void;\n onOrderShipped(event: OrderShippedEvent): void;\n onOrderDelivered(event: OrderDeliveredEvent): void;\n onOrderCancelled(event: OrderCancelledEvent): void;\n}\n\n// Different listeners for different concerns\nclass InventoryAdjuster implements OrderEventListener { /* ... */ }\nclass CustomerNotifier implements OrderEventListener { /* ... */ }\nclass AnalyticsTracker implements OrderEventListener { /* ... */ }","fileName":"observer_interface.ts","language":"typescript"},"type":"code"},{"data":{"content":"**Pattern 5: Factory Interface**\n\nAbstracts object creation, allowing different creation strategies."},"type":"text"},{"data":{"code":"interface NotificationFactory {\n createNotification(type: NotificationType, content: NotificationContent): Notification;\n}\n\n// Different factories for different contexts\nclass EmailNotificationFactory implements NotificationFactory { /* ... */ }\nclass PushNotificationFactory implements NotificationFactory { /* ... */ }\nclass SMSNotificationFactory implements NotificationFactory { /* ... */ }\nclass AggregateNotificationFactory implements NotificationFactory { /* combines multiple */ }","fileName":"factory_interface.ts","language":"typescript"},"type":"code"},{"data":{"icon":"Info","title":"Patterns Are Guides, Not Rules","content":"These patterns are starting points, not prescriptions. Adapt them to your specific needs. The goal is to create useful abstractions, not to rigidly follow pattern templates. Sometimes an interface doesn't fit any named pattern but is exactly right for your situation.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"interfaces-in-practice","title":"Interfaces in Practice: A Case Study","content":[{"data":{"content":"Let's walk through a realistic scenario to see how interfaces enable dependency inversion in a complete system.\n\n**Scenario: Order Processing System**\n\nWe're building an e-commerce order processing system. Orders must be:\n1. Validated against inventory\n2. Charged via payment processor\n3. Recorded in the database\n4. Customer notified\n5. Analytics tracked\n\n**The Interface-Driven Architecture:**"},"type":"text"},{"data":{"code":"$83","fileName":"order_processing_system.ts","language":"typescript"},"type":"code"},{"data":{"content":"**The Power of This Design:**\n\nThe `OrderProcessor` class is completely isolated from:\n- Whether inventory is tracked in a local database, ERP system, or microservice\n- Whether payments go through Stripe, Braintree, or a custom processor\n- Whether orders are stored in PostgreSQL, MongoDB, or event sourced\n- Whether notifications use email, SMS, push, or all three\n- Whether analytics goes to Mixpanel, Amplitude, or a data warehouse\n\nThis means:\n\n**1. Testing is Trivial:**"},"type":"text"},{"data":{"code":"$84","fileName":"order_processor_test.ts","language":"typescript"},"type":"code"},{"data":{"content":"**2. Replacing Components is Safe:**\n\nWhen migrating from Stripe to a new payment processor, you:\n- Create `NewPaymentProcessor implements PaymentProcessor`\n- Test the new implementation independently\n- Swap the dependency injection configuration\n- `OrderProcessor` never changes\n\n**3. Different Configurations for Different Contexts:**\n\n- Development: Mock implementations\n- Staging: Real but sandboxed implementations\n- Production: Full production implementations\n- Load Testing: Implementations with chaos injection\n\nAll without any changes to the core business logic."},"type":"text"},{"data":{"icon":"CheckCircle","title":"The Interface Dividend","content":"The upfront investment in defining clean interfaces pays dividends throughout the system's lifetime. Every new requirement, bug fix, or infrastructure change is easier because the core logic is insulated from the changing periphery. This is the essence of sustainable software architecture.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-takeaways","title":"Summary: Interfaces as the Foundation of Abstraction","content":[{"data":{"content":"We've explored interfaces from their philosophical foundations to practical application. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Interfaces define contracts, not implementations** — They specify what operations are available without dictating how those operations are performed.","**Interfaces enable dependency inversion** — By placing an interface between components, both sides depend on the abstraction rather than each other.","**Good interfaces are consumer-driven** — Design from the perspective of what clients need, not what implementations can do.","**Interface Segregation matters** — Keep interfaces small and focused; fat interfaces create unnecessary coupling.","**Interfaces should be stable** — Treat published interfaces as contracts; prefer adding new interfaces over changing existing ones.","**Interfaces enable testing** — Mock implementations make isolated unit testing practical.","**Interfaces enable flexibility** — Swap implementations without affecting consumers; evolve systems incrementally."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The Architectural Perspective:**\n\nInterfaces are not just a language feature—they are the primary mechanism for creating architectural boundaries. In a well-designed system, interfaces define the seams along which components can be developed, tested, deployed, and replaced independently. They are the contracts that make large-scale software possible.\n\n**What's Next:**\n\nNow that we understand interfaces as abstraction mechanisms, we'll explore a crucial question: Who owns these interfaces? The answer has profound implications for system architecture, and getting it wrong is one of the most common DIP violations. The next page examines the **Ownership of Abstractions** and why it matters."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand interfaces as the primary abstraction mechanism for achieving dependency inversion. You've seen how interfaces create stable boundaries, enable testing, and provide flexibility. Next, we'll explore who should own these interfaces—a decision that determines whether DIP actually works in practice.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_37e95afe6824a4812314a4d57bfc1b21","title":"Ownership of Abstractions","order":1,"content":null,"isLocked":true},{"id":"seed_ad8e840f87d906326244d179820e4248","title":"Abstractions at Boundaries","order":2,"content":null,"isLocked":true},{"id":"seed_9db2d9676021cbd2532d932a5ee91262","title":"Stable Abstractions Principle","order":3,"content":null,"isLocked":true}]}}