7a:T431,Imagine you're working with a `BankAccount` class in a financial system. You call `getBalance()` and receive `-$500,000`. But wait—wasn't this account type supposed to be a "Non-Negative Balance Account"? How did this happen? The answer lies in **class invariants**—properties that must always be true for an object, from the moment it's created until the moment it's destroyed. When these invariants are violated, objects enter impossible states, and systems fail in unpredictable ways. **An invariant isn't just documentation. It's a contract that every method must maintain.** The `BankAccount` that went negative had an invariant: `balance >= 0`. Somewhere, some method—perhaps in a subclass—violated this invariant. The result? Data corruption flowing through the system, affecting calculations, reports, and potentially real-world financial decisions. This page explores the concept of class invariants: what they are, why they're critical to reliable software, and how they form the foundation of the Liskov Substitution Principle's behavioral contracts.7b:T45b,A **class invariant** is a condition that is always true for every valid instance of a class, throughout its entire lifetime. From the moment an object is constructed until the moment it goes out of scope, invariants must hold. **Formal definition:** > A class invariant is a logical condition involving the instance variables of a class that must be true before and after every method call. If the invariant ever becomes false, the object is in an invalid state. Let's unpack this carefully: 1. **"Always true"** means there's never a moment (between method calls) when the invariant can be false 2. **"Before and after every method"** means methods can temporarily break invariants during execution, but must restore them before returning 3. **"Invalid state"** means the object's data no longer represents a meaningful entity Invariants are different from preconditions and postconditions: - **Preconditions**: What must be true *before* a method is called - **Postconditions**: What must be true *after* a method completes - **Invariants**: What must be true *always*, independent of any specific method7c:T8b4,/** * A DateRange class with a clear invariant: * INVARIANT: startDate <= endDate (start never after end) * * This invariant must be true: * - After construction * - After every method call * - During the object's entire lifetime */ class DateRange { private startDate: Date; private endDate: Date; // INVARIANT: startDate <= endDate constructor(start: Date, end: Date) { // Check invariant at construction time if (start > end) { throw new Error("Invalid DateRange: start cannot be after end"); } this.startDate = start; this.endDate = end; // Invariant established: startDate <= endDate ✓ } /** * Move the start date earlier. * This always maintains the invariant since we're moving start earlier. */ extendStart(newStart: Date): void { if (newStart > this.endDate) { throw new Error("Cannot set start after end date"); } this.startDate = newStart; // Invariant maintained: startDate <= endDate ✓ } /** * Move the end date later. * This always maintains the invariant since we're moving end later. */ extendEnd(newEnd: Date): void { if (newEnd < this.startDate) { throw new Error("Cannot set end before start date"); } this.endDate = newEnd; // Invariant maintained: startDate <= endDate ✓ } /** * Shift the entire range by a number of days. * Invariant is maintained because both dates move equally. */ shiftDays(days: number): void { const msPerDay = 24 * 60 * 60 * 1000; const shift = days * msPerDay; // Both dates shift together - invariant cannot be violated this.startDate = new Date(this.startDate.getTime() + shift); this.endDate = new Date(this.endDate.getTime() + shift); // Invariant maintained: startDate <= endDate ✓ } getDurationDays(): number { const ms = this.endDate.getTime() - this.startDate.getTime(); return Math.floor(ms / (24 * 60 * 60 * 1000)); // Note: This method relies on the invariant to return non-negative } }7d:T82b,from datetime import date, timedelta class DateRange: """ A DateRange class with a clear invariant: INVARIANT: start_date <= end_date (start never after end) This invariant must be true: - After construction - After every method call - During the object's entire lifetime """ # INVARIANT: start_date <= end_date def __init__(self, start: date, end: date): # Check invariant at construction time if start > end: raise ValueError("Invalid DateRange: start cannot be after end") self._start_date = start self._end_date = end # Invariant established: start_date <= end_date ✓ def extend_start(self, new_start: date) -> None: """ Move the start date earlier. This always maintains the invariant since we're moving start earlier. """ if new_start > self._end_date: raise ValueError("Cannot set start after end date") self._start_date = new_start # Invariant maintained: start_date <= end_date ✓ def extend_end(self, new_end: date) -> None: """ Move the end date later. This always maintains the invariant since we're moving end later. """ if new_end < self._start_date: raise ValueError("Cannot set end before start date") self._end_date = new_end # Invariant maintained: start_date <= end_date ✓ def shift_days(self, days: int) -> None: """ Shift the entire range by a number of days. Invariant is maintained because both dates move equally. """ delta = timedelta(days=days) # Both dates shift together - invariant cannot be violated self._start_date = self._start_date + delta self._end_date = self._end_date + delta # Invariant maintained: start_date <= end_date ✓ def get_duration_days(self) -> int: # This method relies on the invariant to return non-negative return (self._end_date - self._start_date).days7e:T918,import java.time.LocalDate; import java.time.temporal.ChronoUnit; /** * A DateRange class with a clear invariant: * INVARIANT: startDate <= endDate (start never after end) * * This invariant must be true: * - After construction * - After every method call * - During the object's entire lifetime */ public class DateRange { private LocalDate startDate; private LocalDate endDate; // INVARIANT: startDate <= endDate public DateRange(LocalDate start, LocalDate end) { // Check invariant at construction time if (start.isAfter(end)) { throw new IllegalArgumentException( "Invalid DateRange: start cannot be after end" ); } this.startDate = start; this.endDate = end; // Invariant established: startDate <= endDate ✓ } /** * Move the start date earlier. * This always maintains the invariant since we're moving start earlier. */ public void extendStart(LocalDate newStart) { if (newStart.isAfter(this.endDate)) { throw new IllegalArgumentException( "Cannot set start after end date" ); } this.startDate = newStart; // Invariant maintained: startDate <= endDate ✓ } /** * Move the end date later. * This always maintains the invariant since we're moving end later. */ public void extendEnd(LocalDate newEnd) { if (newEnd.isBefore(this.startDate)) { throw new IllegalArgumentException( "Cannot set end before start date" ); } this.endDate = newEnd; // Invariant maintained: startDate <= endDate ✓ } /** * Shift the entire range by a number of days. * Invariant is maintained because both dates move equally. */ public void shiftDays(long days) { // Both dates shift together - invariant cannot be violated this.startDate = this.startDate.plusDays(days); this.endDate = this.endDate.plusDays(days); // Invariant maintained: startDate <= endDate ✓ } public long getDurationDays() { // This method relies on the invariant to return non-negative return ChronoUnit.DAYS.between(startDate, endDate); } }7f:T557,class Percentage { private value: number; // INVARIANT: 0 <= value <= 100 constructor(value: number) { if (value < 0 || value > 100) { throw new Error("Percentage must be between 0 and 100"); } this.value = value; } add(other: Percentage): Percentage { // Result capped to maintain invariant const sum = Math.min(100, this.value + other.value); return new Percentage(sum); } } class EmailAddress { private readonly address: string; // INVARIANT: address is a valid email format (contains @ and domain) constructor(address: string) { if (!this.isValidEmail(address)) { throw new Error("Invalid email address format"); } this.address = address; } private isValidEmail(email: string): boolean { // Simplified validation const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return pattern.test(email); } } class AgeBracket { private minAge: number; private maxAge: number; // INVARIANT: 0 <= minAge <= maxAge <= 150 constructor(minAge: number, maxAge: number) { if (minAge < 0 || maxAge > 150 || minAge > maxAge) { throw new Error("Invalid age bracket"); } this.minAge = minAge; this.maxAge = maxAge; } }80:T791,class Rectangle { private width: number; private height: number; private area: number; // Cached for performance // INVARIANT: area === width * height (always synchronized) constructor(width: number, height: number) { this.width = width; this.height = height; this.area = width * height; // Establish invariant } setWidth(newWidth: number): void { this.width = newWidth; this.area = this.width * this.height; // Maintain invariant } setHeight(newHeight: number): void { this.height = newHeight; this.area = this.width * this.height; // Maintain invariant } getArea(): number { // Relies on invariant - no recalculation needed return this.area; } } class SortedList { private items: T[]; private comparator: (a: T, b: T) => number; // INVARIANT: For all i < j: comparator(items[i], items[j]) <= 0 // (Items are always in sorted order) constructor(comparator: (a: T, b: T) => number) { this.items = []; this.comparator = comparator; } add(item: T): void { // Binary search to find insertion point - maintains sort invariant let left = 0, right = this.items.length; while (left < right) { const mid = Math.floor((left + right) / 2); if (this.comparator(this.items[mid], item) <= 0) { left = mid + 1; } else { right = mid; } } this.items.splice(left, 0, item); // Invariant maintained: items remain sorted } getMin(): T | undefined { // Relies on invariant: smallest is always at index 0 return this.items[0]; } getMax(): T | undefined { // Relies on invariant: largest is always at last index return this.items[this.items.length - 1]; } }81:T8b4,class BinarySearchTree { private root: TreeNode | null = null; private comparator: (a: T, b: T) => number; // INVARIANT: For every node N: // - All values in N.left subtree < N.value // - All values in N.right subtree > N.value // (Binary Search Tree property) constructor(comparator: (a: T, b: T) => number) { this.comparator = comparator; } insert(value: T): void { // Insert maintains BST invariant by choosing correct position if (!this.root) { this.root = { value, left: null, right: null }; return; } this.insertRecursive(this.root, value); // Invariant maintained: BST property preserved } private insertRecursive(node: TreeNode, value: T): void { const comparison = this.comparator(value, node.value); if (comparison < 0) { // Value is less - goes in left subtree (maintains invariant) if (node.left) { this.insertRecursive(node.left, value); } else { node.left = { value, left: null, right: null }; } } else { // Value is greater/equal - goes in right subtree (maintains invariant) if (node.right) { this.insertRecursive(node.right, value); } else { node.right = { value, left: null, right: null }; } } } contains(value: T): boolean { // Search relies on BST invariant for O(log n) lookup return this.searchRecursive(this.root, value); } private searchRecursive(node: TreeNode | null, value: T): boolean { if (!node) return false; const comparison = this.comparator(value, node.value); if (comparison === 0) return true; // Invariant guarantees we only need to search one subtree if (comparison < 0) { return this.searchRecursive(node.left, value); } else { return this.searchRecursive(node.right, value); } } } interface TreeNode { value: T; left: TreeNode | null; right: TreeNode | null; }82:T5e8,class LinkedList { private head: ListNode | null = null; private tail: ListNode | null = null; private count: number = 0; // INVARIANT 1: count === actual number of nodes in list // INVARIANT 2: if count === 0, then head === null && tail === null // INVARIANT 3: if count > 0, then head !== null && tail !== null // INVARIANT 4: tail.next === null (tail is always the last node) add(value: T): void { const newNode: ListNode = { value, next: null }; if (this.tail) { this.tail.next = newNode; this.tail = newNode; } else { this.head = newNode; this.tail = newNode; } this.count++; // Maintain count invariant // All invariants maintained } removeFirst(): T | undefined { if (!this.head) return undefined; const value = this.head.value; this.head = this.head.next; if (!this.head) { this.tail = null; // Maintain invariant 2 } this.count--; // Maintain count invariant // All invariants maintained return value; } size(): number { // Relies on count invariant - O(1) instead of traversing return this.count; } isEmpty(): boolean { // Relies on invariant 2 return this.count === 0; } } interface ListNode { value: T; next: ListNode | null; }83:T7b7,// WITHOUT invariant guarantees - defensive everywhere class UntrustedRectangle { width: number | null = null; height: number | null = null; getArea(): number | null { // Must check everything because nothing is guaranteed if (this.width === null || this.height === null) { return null; } if (this.width < 0 || this.height < 0) { return null; // Or throw? Caller doesn't know what to expect } return this.width * this.height; } getPerimeter(): number | null { // Same defensive checks repeated everywhere if (this.width === null || this.height === null) { return null; } if (this.width < 0 || this.height < 0) { return null; } return 2 * (this.width + this.height); } } // WITH invariant guarantees - clean and focused class TrustedRectangle { // INVARIANT: width > 0, height > 0 (always positive, never null) private constructor( private readonly width: number, private readonly height: number ) {} static create(width: number, height: number): TrustedRectangle { // Invariant enforced at construction if (width <= 0 || height <= 0) { throw new Error("Dimensions must be positive"); } return new TrustedRectangle(width, height); } getArea(): number { // No checks needed - invariant guarantees valid dimensions return this.width * this.height; } getPerimeter(): number { // Clean implementation relying on invariant return 2 * (this.width + this.height); } scale(factor: number): TrustedRectangle { if (factor <= 0) { throw new Error("Scale factor must be positive"); } // Result automatically satisfies invariant return new TrustedRectangle(this.width * factor, this.height * factor); } }84:T8fc,class SortedArray { private items: T[]; private comparator: (a: T, b: T) => number; // INVARIANT: items is always sorted according to comparator constructor(comparator: (a: T, b: T) => number) { this.items = []; this.comparator = comparator; } /** * Because of the invariant, we can use binary search. * O(log n) instead of O(n) for unsorted arrays. */ contains(item: T): boolean { return this.binarySearch(item) !== -1; } /** * Find minimum in O(1) because invariant guarantees smallest is first. */ min(): T | undefined { return this.items[0]; // Invariant: first is always smallest } /** * Find maximum in O(1) because invariant guarantees largest is last. */ max(): T | undefined { return this.items[this.items.length - 1]; // Invariant: last is always largest } /** * Merge two sorted arrays in O(n + m) because both maintain sort invariant. * Without the invariant, this would require O((n+m) log(n+m)) to sort. */ merge(other: SortedArray): SortedArray { const result = new SortedArray(this.comparator); let i = 0, j = 0; // Merge in sorted order - only possible because both are sorted while (i < this.items.length && j < other.items.length) { if (this.comparator(this.items[i], other.items[j]) <= 0) { result.items.push(this.items[i++]); } else { result.items.push(other.items[j++]); } } // Append remaining items (already sorted) while (i < this.items.length) result.items.push(this.items[i++]); while (j < other.items.length) result.items.push(other.items[j++]); return result; // Result also maintains invariant } private binarySearch(item: T): number { let left = 0, right = this.items.length - 1; while (left <= right) { const mid = Math.floor((left + right) / 2); const cmp = this.comparator(this.items[mid], item); if (cmp === 0) return mid; if (cmp < 0) left = mid + 1; else right = mid - 1; } return -1; } }85:T775,class NonNegativeBalance { // INVARIANT: balance >= 0 private balance: number; constructor(initialBalance: number) { if (initialBalance < 0) { throw new Error("Initial balance cannot be negative"); } this.balance = initialBalance; } deposit(amount: number): void { if (amount < 0) { throw new Error("Cannot deposit negative amount"); } this.balance += amount; // Invariant maintained: adding positive to non-negative stays non-negative } withdraw(amount: number): void { if (amount < 0) { throw new Error("Cannot withdraw negative amount"); } if (amount > this.balance) { throw new Error("Insufficient funds"); } this.balance -= amount; // Invariant maintained: we checked amount <= balance } getBalance(): number { return this.balance; // Caller can trust this is >= 0 } } // Caller code relies on the invariant function calculateInterest(account: NonNegativeBalance): number { const balance = account.getBalance(); // This code TRUSTS that balance >= 0 // No check needed because the invariant guarantees it const rate = 0.05; return balance * rate; // Always non-negative } function displayBalance(account: NonNegativeBalance): string { const balance = account.getBalance(); // Safe to use without checking for negative // The invariant guarantees balance >= 0 return `$${balance.toFixed(2)}`; } function transferSafely( from: NonNegativeBalance, to: NonNegativeBalance, amount: number ): void { // This operation is safe because both accounts maintain invariants from.withdraw(amount); // Will throw if insufficient funds to.deposit(amount); // If we reach here, both accounts still satisfy invariants }86:T5df,// Given this class, what are its invariants? class Order { private items: OrderItem[]; private status: OrderStatus; private total: number; private createdAt: Date; private shippedAt: Date | null; constructor(items: OrderItem[]) { if (items.length === 0) { throw new Error("Order must have at least one item"); } this.items = [...items]; // Defensive copy this.status = OrderStatus.PENDING; this.total = this.calculateTotal(); this.createdAt = new Date(); this.shippedAt = null; } private calculateTotal(): number { return this.items.reduce((sum, item) => sum + item.price * item.quantity, 0); } ship(): void { if (this.status !== OrderStatus.PENDING) { throw new Error("Can only ship pending orders"); } this.status = OrderStatus.SHIPPED; this.shippedAt = new Date(); } getItems(): OrderItem[] { return [...this.items]; // Defensive copy - can't modify internal } } // DISCOVERED INVARIANTS: // 1. items.length > 0 (checked in constructor) // 2. total === sum of item prices * quantities (set at construction) // 3. createdAt is never null (set at construction) // 4. If status === SHIPPED, then shippedAt !== null // 5. If status === PENDING, then shippedAt === null // 6. items array is immutable after construction (defensive copies) // 7. status transitions: PENDING -> SHIPPED (never backwards)72:{"json":{"id":"seed_adf37ed1589a5ff8761a09f512bbda39","slug":"invariants-in-inheritance","category":"System Design (LLD)","topic":"Liskov Substitution Principle","title":"Invariants in Inheritance","description":"Master class invariants—the always-true conditions that define object integrity. Learn how invariants form behavioral contracts, why subclasses must preserve them, and how violations lead to subtle, catastrophic bugs. Understand invariant-safe design for robust inheritance hierarchies.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_ac507b560b331c0b16de24efec026697","title":"Class Invariants - Always-True Conditions","order":0,"content":[{"id":"opening-hook","title":"The Invisible Contract","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand what class invariants are, why they're essential for object integrity, how to identify invariants in your designs, and how invariants create implicit contracts that every method must honor. You'll learn to think about objects not just in terms of behavior, but in terms of the guarantees they must maintain.","variant":"info"},"type":"callout"}]},{"id":"what-are-invariants","title":"What Are Class Invariants?","content":[{"data":{"content":"$7b"},"type":"text"},{"data":{"rows":[["Precondition","Single method call","The caller","Before the method begins execution"],["Postcondition","Single method call","The method implementation","After the method completes execution"],["Invariant","Object lifetime","Every method in the class","Always, except during method execution"]],"caption":"Invariants vs Preconditions vs Postconditions","headers":["Concept","Scope","Who Ensures It","When It Must Hold"]},"type":"table"},{"data":{"fileName":"invariant-basics","languages":[{"code":"$7c","label":"TypeScript","value":"typescript"},{"code":"$7d","label":"Python","value":"python"},{"code":"$7e","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"The Invariant-Method Relationship","content":"Notice how every method in DateRange is designed with the invariant in mind. Methods either verify that their changes won't violate the invariant (and throw if they would), or they make changes that structurally cannot violate the invariant (like shifting both dates together). This is the discipline invariant thinking requires.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"types-of-invariants","title":"Types of Class Invariants","content":[{"data":{"content":"Invariants come in various forms, from simple value constraints to complex relationships between multiple fields. Understanding these categories helps you identify and document invariants in your own classes.\n\n**1. Value Constraints (Bounds, Ranges, Allowed Values)**\n\nThese invariants restrict individual fields to specific domains:"},"type":"text"},{"data":{"fileName":"value-constraints","languages":[{"code":"$7f","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**2. Relationship Invariants (Between Fields)**\n\nThese invariants express that multiple fields must maintain a specific relationship:"},"type":"text"},{"data":{"fileName":"relationship-invariants","languages":[{"code":"$80","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**3. Structural Invariants (Data Structure Integrity)**\n\nThese invariants ensure that internal data structures remain valid:"},"type":"text"},{"data":{"fileName":"structural-invariants","languages":[{"code":"$81","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**4. Count/Size Invariants (Synchronized Counts)**\n\nThese invariants ensure that size or count fields accurately reflect the actual data:"},"type":"text"},{"data":{"fileName":"count-invariants","languages":[{"code":"$82","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"Documenting Invariants","content":"The most important step in working with invariants is making them explicit. Document invariants as comments in your class definition. Future maintainers (including future you) must understand what properties the class guarantees, so they don't accidentally break them when adding new methods.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"why-invariants-matter","title":"Why Invariants Matter","content":[{"data":{"content":"Invariants might seem like additional overhead—extra checks, extra thinking, extra documentation. But they provide profound benefits that compound as systems grow in size and complexity.\n\n**1. Trust and Simplification**\n\nWhen invariants are guaranteed, code can make assumptions without defensive checks:"},"type":"text"},{"data":{"left":[{"data":{"items":["Every method must validate inputs defensively","Callers can't trust returned values","Business logic drowns in validation code","Bugs hide in forgotten edge cases","Code becomes verbose and brittle"],"title":{"icon":"XCircle","text":"Without Invariant Guarantees","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Methods assume valid state on entry","Returned objects are always valid","Business logic is clear and focused","Invalid states are prevented by design","Code is concise and robust"],"title":{"icon":"CheckCircle","text":"With Invariant Guarantees","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"trust-simplification","languages":[{"code":"$83","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**2. Reasoning About Correctness**\n\nInvariants make it possible to reason about program correctness systematically:\n\n- **During code review**: Verify each method maintains invariants\n- **During debugging**: If invariant is violated, you know exactly what broke\n- **During testing**: Tests can verify invariants hold after each operation\n- **During design**: Invariants guide API design and reveal impossible operations\n\n**3. Performance Optimization**\n\nInvariants enable optimizations that would otherwise be unsafe:"},"type":"text"},{"data":{"fileName":"invariant-optimization","languages":[{"code":"$84","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Breaking Invariants Breaks Optimizations","content":"If any code path allows the SortedArray to become unsorted, every optimization based on the sort invariant fails. Binary search returns wrong results. Min/max become incorrect. Merge produces unsorted output. This is why invariant violations are so dangerous—they silently corrupt behavior across the entire class.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"invariants-as-contracts","title":"Invariants as Implicit Contracts","content":[{"data":{"content":"Here's a critical insight: **Class invariants create implicit contracts between the class and all code that uses it.**\n\nWhen you define a class with invariants, you're making promises to callers:\n- \"This BankAccount will never have a negative balance\"\n- \"This DateRange will always have start ≤ end\"\n- \"This SortedList will always be in order\"\n\nCallers rely on these promises. They write code that assumes the invariants are true. If you violate the invariants, you break that code—often in subtle, hard-to-detect ways."},"type":"text"},{"data":{"fileName":"implicit-contracts","languages":[{"code":"$85","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**The Trust Chain:**\n\nInvariants create a chain of trust throughout your codebase:\n\n1. **Class guarantees invariant** → Methods ensure invariants hold after every operation\n2. **Methods rely on invariant** → Internal implementation doesn't re-check what's guaranteed\n3. **Callers rely on invariant** → External code trusts the class promises\n4. **Downstream relies on caller** → Systems built on top trust their building blocks\n\nIf any link in this chain breaks—if any method fails to maintain the invariant—the corruption propagates through the entire chain. Code that was correct becomes incorrect, not because it changed, but because something it trusted broke its promise."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Make Invariants Unbreakable","content":"The best way to maintain invariants is to make them impossible to break. Use private fields with controlled accessors. Validate at construction time. Make objects immutable where possible. The goal is to structure your class so that no sequence of method calls can ever create an invalid state.","variant":"tip"},"type":"callout"},{"data":{"rows":[["Private fields only","External code cannot directly modify state","Always - default approach"],["Validate in constructor","Reject invalid initial states","Always - establish invariant at birth"],["Validate in mutators","Check before every state change","When mutation is necessary"],["Immutability","Objects can't change, so invariants can't be violated post-construction","When feasible - strongest guarantee"],["Factory methods","Control object creation to ensure valid states","Complex initialization logic"],["Defensive copies","Prevent callers from mutating internal state","When returning mutable internals"]],"caption":"Strategies for Maintaining Invariants","headers":["Strategy","How It Works","When to Use"]},"type":"table"}],"titleType":"number","titleNumber":4},{"id":"identifying-invariants","title":"Identifying Invariants in Existing Code","content":[{"data":{"content":"How do you uncover the invariants in code that doesn't document them? This is a critical skill, especially when working with legacy systems or third-party libraries.\n\n**Discovery Techniques:**"},"type":"text"},{"data":{"items":["**Look at constructors**: What validation happens? What must be true for construction to succeed?","**Examine field types**: Are they non-nullable? Bounded? What types were chosen?","**Read setter/mutator methods**: What throws exceptions? What conditions are checked?","**Study getter methods**: What assumptions do they make about internal state?","**Analyze assertions and checks**: What conditions does the code verify?","**Check test cases**: What properties do tests verify? What edge cases are covered?","**Review documentation**: Even informal comments hint at expected properties"],"title":{"icon":"Search","text":"How to Find Hidden Invariants","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"fileName":"discovering-invariants","languages":[{"code":"$86","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**Common Invariant Patterns:**"},"type":"text"},{"data":{"rows":[["Financial","balance >= 0; credits - debits = balance; transaction amounts > 0"],["Collections","size >= 0; size = actual count; indices < size"],["Date/Time","start <= end; duration >= 0; times are in valid ranges"],["Graphs","edge connects valid nodes; no orphan edges; degrees are accurate"],["Trees","one root; no cycles; parent-child links consistent"],["Caches","capacity >= 0; size <= capacity; entries match stored keys"],["User Data","id is unique; email format is valid; required fields are non-null"]],"caption":"Common Invariants in Software Systems","headers":["Domain","Common Invariants"]},"type":"table"},{"data":{"icon":"Info","title":"Document What You Discover","content":"When you discover undocumented invariants, add them to the code as comments. Future maintainers will thank you. Better yet, add assertions or validation that explicitly checks invariants, making violations fail fast and loudly.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"summary","title":"Summary: The Foundation of Object Integrity","content":[{"data":{"content":"We've explored class invariants in depth. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Invariants are always-true conditions** — Properties that must hold from object creation through its entire lifetime","**Invariants come in many forms** — Value constraints, field relationships, structural properties, synchronized counts","**Every method must maintain invariants** — Methods can temporarily break invariants during execution, but must restore them before returning","**Invariants enable trust and optimization** — Code can assume invariant properties without defensive checks","**Invariants create implicit contracts** — Callers rely on invariant properties; violating them breaks downstream code","**Document your invariants explicitly** — Future maintainers must understand what properties the class guarantees"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nUnderstanding invariants is crucial preparation for the next topic: **Preserving Invariants in Subclasses**. When inheritance enters the picture, invariants become even more critical—and more easily violated.\n\nA subclass inherits not just the code of its parent, but also its invariants. If a subclass weakens or breaks these invariants, it violates the Liskov Substitution Principle, causing polymorphic code to fail in subtle, dangerous ways.\n\nYou'll learn exactly how subclasses can accidentally break parent invariants, and how to design inheritance hierarchies that maintain invariant integrity across the entire type hierarchy."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand what class invariants are and why they're fundamental to object integrity. Invariants aren't just nice-to-have documentation—they're the contracts that make polymorphism safe and enable code to trust the objects it works with. Next, we'll explore how subclasses must preserve these invariants to maintain LSP compliance.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":6}],"isLocked":false},{"id":"seed_42f91e8895588fc24a14e1cf62cc8fd5","title":"Preserving Invariants in Subclasses","order":1,"content":null,"isLocked":true},{"id":"seed_3ead52fe97500c92ba0678138d90f15a","title":"Invariant Violations","order":2,"content":null,"isLocked":true},{"id":"seed_1af4ef0008e2038b58639ef9647b61cf","title":"Designing for Invariant Safety","order":3,"content":null,"isLocked":true}]}}