79:T74e,// Example: Relationship Analysis in Practice // STRONG IS-A RELATIONSHIP — Inheritance may be appropriate // A CheckingAccount IS-A BankAccount // - All BankAccount operations make sense for CheckingAccount // - Clients expecting BankAccount can use CheckingAccount safely // - The relationship is stable and domain-grounded public class CheckingAccount extends BankAccount { private double overdraftLimit; @Override public void withdraw(double amount) { // Specializes but maintains the contract if (balance + overdraftLimit >= amount) { balance -= amount; } } } // WEAK IS-A RELATIONSHIP — Composition is likely better // Does a Square IS-A Rectangle? Mathematically yes, but behaviorally? // - Rectangle clients expect independent width/height modification // - Square cannot satisfy this expectation // - The "is-a" creates behavioral surprises // BAD: Inheritance violates LSP public class Square extends Rectangle { @Override public void setWidth(int width) { this.width = width; this.height = width; // Surprise! Side effect violates Rectangle contract } } // GOOD: Composition allows proper modeling public class Square { private int side; public Rectangle asRectangle() { return new Rectangle(side, side); // Explicit conversion } } // AMBIGUOUS RELATIONSHIP — Analyze deeper // Is an Employee a Person? Is a Manager an Employee? // The answer depends on your domain needs: // - If you need polymorphic treatment: consider inheritance // - If roles change over time: composition is better // Composition allows role changes public class Employee { private Person person; // HAS-A person private Role currentRole; // HAS-A role (can change) private Department department; // HAS-A department (can change) }7a:T85d,// Flexibility Analysis Examples // SCENARIO 1: Low flexibility needs // A logging level hierarchy has fixed, well-known variations // Inheritance is reasonable here enum LogLevel { DEBUG, INFO, WARN, ERROR } abstract class Logger { abstract log(level: LogLevel, message: string): void; } class ConsoleLogger extends Logger { /* ... */ } class FileLogger extends Logger { /* ... */ } // SCENARIO 2: High combinatorial flexibility needed // A document can be formatted, encrypted, and compressed // With inheritance, you'd need: // - FormattedDocument, EncryptedDocument, CompressedDocument // - FormattedEncryptedDocument, FormattedCompressedDocument // - EncryptedCompressedDocument, FormattedEncryptedCompressedDocument // That's 2^n classes for n features! // With composition, you compose decorators: interface Document { getContent(): string; } class BaseDocument implements Document { constructor(private content: string) {} getContent() { return this.content; } } class FormattedDocument implements Document { constructor(private wrapped: Document) {} getContent() { return format(this.wrapped.getContent()); } } class EncryptedDocument implements Document { constructor(private wrapped: Document) {} getContent() { return encrypt(this.wrapped.getContent()); } } // Compose any combination: const doc = new FormattedDocument( new EncryptedDocument( new BaseDocument("Hello") ) ); // SCENARIO 3: Runtime behavior switching needed // A payment processor needs to switch providers based on context // Composition enables runtime switching; inheritance cannot interface PaymentProvider { processPayment(amount: number): Promise; } class PaymentProcessor { private provider: PaymentProvider; setProvider(provider: PaymentProvider) { this.provider = provider; // Runtime switching! } async process(amount: number) { return this.provider.processPayment(amount); } } // Switch providers at runtime based on conditions processor.setProvider( amount > 10000 ? new HighValueProvider() : new StandardProvider() );7b:T421,**When Tight Coupling Is Acceptable:** Inheritance's tight coupling is acceptable when: 1. **The parent is stable and unlikely to change** — If you control the parent and can guarantee stability, the coupling risk is low. 2. **The coupling is intentional and desired** — Sometimes you *want* children to be tightly coupled to the parent (e.g., framework extension points). 3. **The hierarchy is small and cohesive** — A shallow hierarchy with few subclasses is more manageable. 4. **The domain demands it** — Some domain models genuinely require type hierarchies for proper expression. **When Tight Coupling Is Problematic:** 1. **The parent is external or unstable** — If you don't control the parent, changes can break your code without warning. 2. **Multiple teams work on the hierarchy** — Coordination becomes increasingly difficult. 3. **The component will be reused broadly** — Tight coupling makes reuse in different contexts difficult. 4. **Testing is a priority** — High coupling makes isolated testing nearly impossible.7c:T96c,// Coupling Assessment Examples // ACCEPTABLE COUPLING: You own both classes, they evolve together // This is a closed, cohesive hierarchy within your control public abstract class AbstractValidator { protected final List rules; protected AbstractValidator() { this.rules = initializeRules(); } protected abstract List initializeRules(); public final ValidationResult validate(Object target) { for (ValidationRule rule : rules) { if (!rule.isValid(target)) { return ValidationResult.failure(rule.getMessage()); } } return ValidationResult.success(); } } // Subclass IS tightly coupled to AbstractValidator's implementation // But this is acceptable because: // - You control AbstractValidator // - The pattern is well-documented (Template Method) // - Changes will be coordinated public class EmailValidator extends AbstractValidator { @Override protected List initializeRules() { return List.of( new NotNullRule(), new EmailFormatRule() ); } } // PROBLEMATIC COUPLING: Inheriting from external/unstable class // BAD: Inheriting from a framework class you don't control public class MySpecialArrayList extends ArrayList { private int addCount = 0; @Override public boolean add(String element) { addCount++; return super.add(element); } @Override public boolean addAll(Collection c) { addCount += c.size(); return super.addAll(c); // Does ArrayList.addAll call add()? Depends on version! } public int getAddCount() { return addCount; // May be wrong due to internal implementation dependencies } } // GOOD: Composition avoids the fragile base class problem public class CountingList { private final List delegate = new ArrayList<>(); private int addCount = 0; public boolean add(T element) { addCount++; return delegate.add(element); } public boolean addAll(Collection c) { addCount += c.size(); return delegate.addAll(c); // No implementation dependency! } public int getAddCount() { return addCount; // Always correct } // Delegate other methods as needed }71:{"json":{"id":"seed_7fa034ada602b2ee1bbfdf2d9bb49925","slug":"when-to-use-inheritance-vs-composition","category":"System Design (LLD)","topic":"When to Use Inheritance vs Composition","title":"When to Use Inheritance vs Composition — Making the Right Choice","description":"Master the art of choosing between inheritance and composition through a systematic decision framework. Learn to recognize the contexts where each approach excels, understand hybrid strategies, and develop the judgment to make optimal design decisions.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_71335f779ff060b50748664349a944f0","title":"Decision Framework","order":0,"content":[{"id":"opening-hook","title":"Beyond Rules of Thumb","content":[{"data":{"content":"Every experienced software engineer has faced this pivotal moment: staring at a design problem, knowing that both inheritance and composition *could* solve it, but uncertain which choice will serve the system well as it evolves. The decision feels consequential because it is—the wrong choice creates technical debt that compounds over years.\n\nYet too often, this decision is made based on incomplete heuristics: **\\\"Favor composition\\\"**—yes, but when is inheritance actually the better choice? **\\\"Use inheritance for is-a relationships\\\"**—but the is-a test alone is insufficient, as countless Rectangle-Square debacles have demonstrated.\n\nWhat we need isn't another simplistic rule. We need a **systematic decision framework**—a structured approach that considers multiple dimensions of the design problem and guides us toward the choice that best serves our actual requirements."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will possess a comprehensive decision framework for choosing between inheritance and composition. You'll understand the key questions to ask, the dimensions to evaluate, and how to weigh competing concerns. This framework transforms an often uncertain decision into an informed, defensible one.","variant":"info"},"type":"callout"}]},{"id":"why-framework-necessary","title":"Why a Framework Is Necessary","content":[{"data":{"content":"Before presenting the framework, let's understand why simple rules fail us in practice.\n\n**The Inadequacy of Simple Heuristics**\n\nConsider the most common guidance:\n\n- **\\\"Favor composition over inheritance\\\"** — This tells us to *prefer* composition, but offers no guidance on *when* inheritance is actually appropriate. Taken literally, we'd never use inheritance, which ignores its legitimate uses.\n\n- **\\\"Use inheritance for is-a relationships\\\"** — This is a necessary but insufficient condition. A Square mathematically *is-a* Rectangle, yet the famous example demonstrates that inheritance here violates behavioral substitutability.\n\n- **\\\"Use composition for has-a relationships\\\"** — While helpful, this doesn't address the many cases where the relationship is ambiguous, or where a design could be modeled either way."},"type":"text"},{"data":{"items":["**Context blindness** — Simple rules ignore the specific constraints and requirements of your particular design problem.","**Binary thinking** — Real designs often need nuanced combinations of both approaches, not an either/or choice.","**Temporal myopia** — Rules don't account for how requirements and understanding will evolve over time.","**Trade-off ignorance** — Every design choice involves trade-offs; rules don't help you weigh competing concerns.","**Domain variance** — The \\\"right\\\" choice varies significantly across different domains, team sizes, and system lifespans."],"title":{"icon":"AlertCircle","text":"Why Simple Rules Fail","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**The Need for Dimensional Analysis**\n\nEffective decision-making requires analyzing the problem across multiple dimensions simultaneously:\n\n- What is the **fundamental nature of the relationship** between the types?\n- What **degree of flexibility** will the design require over its lifetime?\n- What are the **coupling implications** of each approach in this context?\n- How does the choice affect **testability** and **maintainability**?\n- What do the **framework and ecosystem** constraints dictate?\n- What is the **team's experience** and the organization's conventions?\n\nA framework organizes these considerations into a coherent decision process."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Frameworks Enable Judgment, Not Replace It","content":"The goal of a decision framework is not to mechanically produce answers but to structure your thinking. It ensures you consider relevant factors systematically rather than overlooking crucial dimensions. The final judgment remains yours—the framework just makes that judgment better informed.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"framework-overview","title":"The Decision Framework Overview","content":[{"data":{"content":"The decision framework consists of **five key dimensions** that you evaluate for each design choice. Each dimension contributes evidence toward either inheritance or composition, and the overall pattern of evidence guides your decision.\n\n**The Five Dimensions:**\n\n1. **Relationship Analysis** — Is this truly an is-a relationship with behavioral substitutability?\n2. **Flexibility Requirements** — How much will the behavior need to change over time?\n3. **Coupling Assessment** — What are the coupling implications in this specific context?\n4. **Constraint Evaluation** — What do frameworks, languages, and ecosystems require?\n5. **Practical Considerations** — What do team capabilities and organizational context suggest?"},"type":"text"},{"data":{"height":"400px","mermaidSyntax":"flowchart TB\n Start[Design Choice Needed] --> D1[Dimension 1: Relationship Analysis]\n D1 --> D2[Dimension 2: Flexibility Requirements]\n D2 --> D3[Dimension 3: Coupling Assessment]\n D3 --> D4[Dimension 4: Constraint Evaluation]\n D4 --> D5[Dimension 5: Practical Considerations]\n D5 --> Weigh[Weigh Evidence]\n Weigh --> Decision{Decision}\n Decision --> |Strong inheritance signals| Inheritance[Use Inheritance]\n Decision --> |Strong composition signals| Composition[Use Composition]\n Decision --> |Mixed signals| Hybrid[Consider Hybrid Approach]"},"type":"mermaid-excalidraw"},{"data":{"content":"**Framework Application Process:**\n\n1. **Evaluate each dimension** — For each dimension, assess whether the evidence points toward inheritance, composition, or is neutral.\n\n2. **Note dimension strength** — Some dimensions may provide strong signals, others weak. A dimension that provides a strong signal carries more weight.\n\n3. **Look for patterns** — If most dimensions point the same direction, the choice is clear. If signals conflict, deeper analysis is needed.\n\n4. **Consider hybrid approaches** — When signals are mixed, a combination of inheritance and composition may be optimal.\n\n5. **Document your reasoning** — The framework provides vocabulary to explain and defend your design decisions.\n\nLet's examine each dimension in depth."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"dimension-relationship","title":"Dimension 1: Relationship Analysis","content":[{"data":{"content":"The first and most fundamental dimension examines **the nature of the relationship between types**. This goes beyond the simple \\\"is-a\\\" test to consider behavioral substitutability and domain semantics.\n\n**The Enhanced Is-A Test**\n\nThe traditional is-a test asks: \\\"Is a B always an A?\\\"\n\nThe *enhanced* is-a test adds: **\\\"Can a B always substitute for an A in all behavioral contexts, satisfying all client expectations?\\\"**\n\nThis addition is crucial. It's the difference between mathematical categorization and behavioral compatibility."},"type":"text"},{"data":{"rows":[["Is a B conceptually a kind of A?","Domain relationship — does the language make sense?"],["Can B substitute for A everywhere A is expected?","Behavioral compatibility — Liskov Substitution Principle"],["Does B maintain all invariants that clients of A expect?","Contract preservation — no surprises for clients"],["If A changes its interface, should B also change?","Coupling appropriateness — should they evolve together?"],["Is the inheritance relationship stable over time?","Temporal stability — will this remain true?"]],"caption":"Enhanced Is-A Test Questions","headers":["Question","What You're Assessing"]},"type":"table"},{"data":{"content":"**Signals Toward Inheritance:**\n\n- All enhanced is-a questions are answered \\\"yes\\\"\n- The relationship is deeply rooted in the domain, not an implementation convenience\n- The subtype specializes behavior within the contracts of the supertype\n- The hierarchy is stable and unlikely to require restructuring\n\n**Signals Toward Composition:**\n\n- The is-a relationship exists but behavioral substitutability is questionable\n- The relationship feels like an implementation shortcut rather than domain truth\n- The \\\"subtype\\\" would violate expectations if used polymorphically\n- Multiple possible categorizations exist (a thing could belong to multiple hierarchies)\n- The relationship might change or become more nuanced over time"},"type":"text"},{"data":{"fileName":"relationship-analysis-examples","languages":[{"code":"$79","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"The Temporal Dimension of Relationships","content":"Relationships that seem permanent today may become fluid tomorrow. A 'Product IS-A DigitalProduct' might seem stable until physical products are introduced. Always ask: 'In what ways might this relationship evolve?' If change is plausible, composition provides an escape hatch that inheritance does not.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"dimension-flexibility","title":"Dimension 2: Flexibility Requirements","content":[{"data":{"content":"The second dimension assesses **how much flexibility the design will need over its lifetime**. This is perhaps the dimension where composition most often wins, because it provides fundamentally more flexibility.\n\n**Types of Flexibility:**\n\n- **Behavioral flexibility** — Can behavior be changed, extended, or configured?\n- **Structural flexibility** — Can the relationship structure be modified?\n- **Temporal flexibility** — Can things change at runtime, not just compile time?\n- **Combinatorial flexibility** — Can different behaviors be combined in different ways?"},"type":"text"},{"data":{"left":[{"data":{"items":["Behavior fixed at compile time","Class identity permanent for object lifetime","Extension requires new subclasses","Combinations require hierarchy explosion","Runtime behavior switching impossible"],"title":{"icon":"XCircle","text":"Inheritance Flexibility","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Behavior configurable at runtime","Component relationships can change","Extension via new component implementations","Combinations via component assembly","Behavior switching through delegation"],"title":{"icon":"CheckCircle","text":"Composition Flexibility","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Key Flexibility Questions:**\n\n1. **Will behavior need to change at runtime?**\n - If yes: Strong signal toward composition\n - If no: Neutral\n\n2. **Will there be many behavior combinations?**\n - If yes: Composition avoids combinatorial explosion\n - If few, stable combinations: Inheritance may suffice\n\n3. **How often will requirements change?**\n - Frequent changes: Composition adapts more easily\n - Stable, well-understood domain: Inheritance is less risky\n\n4. **Is the variation axis well-understood?**\n - If you know exactly what varies: Either approach can work\n - If variation is uncertain: Composition provides more options"},"type":"text"},{"data":{"fileName":"flexibility-analysis","languages":[{"code":"$7a","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"The Combinatorial Explosion Problem","content":"When you have N independent dimensions of variation, inheritance requires up to 2^N classes to cover all combinations. This 'class explosion' is a powerful signal toward composition, which handles the same variations with N component types that can be freely combined.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"dimension-coupling","title":"Dimension 3: Coupling Assessment","content":[{"data":{"content":"The third dimension examines **the coupling implications of each approach in your specific context**. While inheritance generally creates tighter coupling, the *acceptability* of that coupling depends on your design goals.\n\n**Understanding Coupling Depth:**\n\nInheritance and composition create different *types* of coupling:\n\n- **Inheritance coupling** — Subclass is coupled to parent's *implementation*, including protected members, method call patterns, and internal state assumptions.\n\n- **Composition coupling** — Client is coupled only to the component's *interface*. Implementation details are hidden."},"type":"text"},{"data":{"rows":[["Interface coupling","Yes — must match parent interface","Yes — must match component interface"],["Implementation coupling","Yes — depends on how parent works","No — hidden behind interface"],["Change propagation","High — parent changes may break children","Low — internal changes are hidden"],["Compile-time dependency","Strong — child cannot exist without parent","Weaker — can use interfaces"],["Testing isolation","Hard — requires parent or hierarchy","Easy — can mock components"]],"caption":"Coupling Comparison by Aspect","headers":["Coupling Aspect","Inheritance","Composition"]},"type":"table"},{"data":{"content":"$7b"},"type":"text"},{"data":{"fileName":"coupling-assessment","languages":[{"code":"$7c","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"The 'Control' Heuristic","content":"A useful heuristic: Inheritance from classes you control is far less risky than inheritance from classes you don't. If you don't own and can't modify the parent class, strongly prefer composition to insulate yourself from uncontrollable changes.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"dimension-constraints","title":"Dimension 4: Constraint Evaluation","content":[{"data":{"content":"The fourth dimension considers **external constraints** that may influence or dictate your choice. These are factors outside the pure design realm that nonetheless shape what's practical.\n\n**Types of Constraints:**\n\n1. **Language constraints** — What does your programming language allow or encourage?\n2. **Framework constraints** — What does the framework you're using require?\n3. **Library constraints** — What patterns do the libraries you depend on expect?\n4. **Organizational constraints** — What are your team's conventions and capabilities?\n5. **Performance constraints** — Are there measurable performance implications?"},"type":"text"},{"data":{"items":["**Java** — Single inheritance of classes, multiple interface implementation. Abstract classes provide partial implementation. Favors composition for flexibility, inheritance for framework extension points.","**TypeScript/JavaScript** — Class inheritance exists, but the dynamic nature favors composition. Mixins provide an alternative pattern. The ecosystem generally prefers composition.","**Python** — Multiple inheritance available (with MRO complexity). Both patterns work; duck typing reduces the need for interface hierarchies. Composition is generally preferred.","**Go** — No class inheritance at all. Embedding provides limited composition-like behavior. Forces composition thinking by design.","**Rust** — No class inheritance. Traits provide polymorphism. Composition is the only option for code reuse across types.","**C++** — Full multiple inheritance with associated complexity. Virtual inheritance addresses diamond problem. Both patterns fully supported."],"title":{"icon":"Info","text":"Language-Specific Considerations","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**Framework Requirements:**\n\nMany frameworks have strong opinions about inheritance vs composition:\n\n- **Servlet API** — Expects you to extend `HttpServlet`. Inheritance is mandatory for the extension point.\n\n- **JUnit 3** — Required extending `TestCase`. This was inheritance-based.\n\n- **JUnit 4/5** — Uses annotations and composition. No inheritance required.\n\n- **Spring Framework** — Historically used abstract base classes; modern Spring strongly favors interface-based composition and dependency injection.\n\n- **React** — Earlier versions required extending `React.Component`. Modern React uses function components with hooks—pure composition.\n\n**The Lesson:** Framework evolution generally moves from inheritance toward composition, reflecting industry learning."},"type":"text"},{"data":{"rows":[["Framework requires class extension","Strong","—"],["Language lacks inheritance (Go, Rust)","—","Mandatory"],["Library provides abstract base classes","Moderate","—"],["Team experienced with composition patterns","—","Moderate"],["Performance-critical hot path","Evaluate","Evaluate"],["Must integrate with legacy inheritance hierarchy","Strong","—"]],"caption":"Constraint-Driven Decision Signals","headers":["Constraint Type","Inheritance Signal","Composition Signal"]},"type":"table"},{"data":{"icon":"Info","title":"Performance Considerations","content":"In most business applications, the performance difference between inheritance and composition is negligible. Virtual method dispatch (inheritance) and interface dispatch (composition) are both highly optimized in modern runtimes. Only in extreme hot paths should performance influence this choice—and even then, measure before deciding.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"dimension-practical","title":"Dimension 5: Practical Considerations","content":[{"data":{"content":"The final dimension addresses **practical, contextual factors** that influence what actually works for your team and situation. These \\\"soft\\\" factors often determine success as much as technical considerations.\n\n**Team and Organizational Context:**\n\n1. **Team familiarity** — Is the team more experienced with inheritance or composition patterns? The better-understood approach may succeed where the theoretically superior approach struggles.\n\n2. **Codebase consistency** — What patterns does the existing codebase use? Consistency has value; mixing approaches without reason creates confusion.\n\n3. **Code ownership** — Do multiple teams work on related classes? Inheritance creates coordination challenges across team boundaries.\n\n4. **Review and onboarding** — Which approach will be easier for new team members to understand and for code reviewers to evaluate?"},"type":"text"},{"data":{"items":["**Code volume** — Composition often requires more explicit code (delegation methods). Inheritance provides automatic method inheritance. For large interfaces, the boilerplate difference is significant.","**Discoverability** — Inheritance makes available methods obvious in the type hierarchy. Composition requires examining what's composed. IDE support mitigates but doesn't eliminate this.","**Debugging complexity** — Inheritance debugging follows the class hierarchy. Composition debugging follows the delegation chain. Neither is inherently simpler; familiarity matters.","**Refactoring ease** — Refactoring from inheritance to composition is generally harder than the reverse. If uncertain, starting with composition gives more options.","**Testing infrastructure** — Does your team have strong mocking/stubbing infrastructure? Composition's testing advantages are only realized if the infrastructure exists."],"title":{"icon":"Target","text":"Practical Trade-off Considerations","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Project Lifecycle Considerations:**\n\n- **Early-stage projects** — You understand the domain poorly. Composition provides more options for change.\n\n- **Mature, stable domains** — You understand what varies and what doesn't. Inheritance for stable parts is lower risk.\n\n- **Throwaway/prototype code** — Speed matters more than flexibility. Use whatever is faster to write.\n\n- **Long-lived production systems** — Maintainability matters most. Composition generally wins for longevity.\n\n**The Right Question:**\n\nUltimately, the practical question is: \\\"What will help this team, working on this system, at this stage, succeed?\\\" Technical superiority that the team can't execute doesn't help."},"type":"text"},{"data":{"icon":"Lightbulb","title":"When Uncertain, Prefer Composition","content":"If after analyzing all dimensions the choice remains unclear, defaulting to composition is generally the safer bet. Composition preserves more options for future change, and refactoring from composition to inheritance (if you later determine inheritance is better) is typically easier than the reverse.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"framework-application","title":"Applying the Framework","content":[{"data":{"content":"Let's consolidate the framework into an actionable decision process.\n\n**Step-by-Step Application:**\n\n1. **State the design choice clearly** — \\\"Should X inherit from Y or use Y via composition?\\\"\n\n2. **Evaluate each dimension** — For each of the five dimensions, note whether evidence points toward inheritance, composition, or is neutral.\n\n3. **Weight by signal strength** — Strong signals count more. A weak signal toward inheritance doesn't override a strong signal toward composition.\n\n4. **Look at the overall pattern** — Are signals predominantly in one direction? Or mixed?\n\n5. **Make the decision** — Choose the approach supported by the weight of evidence. If mixed, consider hybrid approaches.\n\n6. **Document your reasoning** — Record why you made this choice for future reference."},"type":"text"},{"data":{"rows":[["Relationship","True is-a + behavioral substitutability","Has-a, uses-a, or questionable is-a"],["Flexibility","Stable variations, no runtime changes","Runtime changes, combinatorial variations"],["Coupling","You control parent, intentional coupling","External parent, broad reuse, testing priority"],["Constraints","Framework requires inheritance","Language favors composition"],["Practical","Team familiar with inheritance patterns","Uncertain domain, long-lived system"]],"caption":"Decision Framework Quick Reference","headers":["Dimension","Inheritance Signals","Composition Signals"]},"type":"table"},{"data":{"content":"**What's Next:**\n\nNow that you have the overall framework, the following pages dive deep into specific scenarios:\n\n- **Page 2: Inheritance-Appropriate Scenarios** — When inheritance is genuinely the right choice.\n- **Page 3: Composition-Appropriate Scenarios** — When composition clearly wins.\n- **Page 4: Hybrid Approaches** — Combining both techniques effectively."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now possess a comprehensive framework for deciding between inheritance and composition. This systematic approach considers relationship analysis, flexibility requirements, coupling assessment, constraint evaluation, and practical considerations. Next, we'll explore specific scenarios where inheritance is genuinely appropriate.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_501eb899233fd101ab12ce7076c21832","title":"Inheritance-Appropriate Scenarios","order":1,"content":null,"isLocked":true},{"id":"seed_86d5e472b44d1dcb0af227a44097c686","title":"Composition-Appropriate Scenarios","order":2,"content":null,"isLocked":true},{"id":"seed_a0640f9515058305c6a2b02420c491f0","title":"Hybrid Approaches","order":3,"content":null,"isLocked":true}]}}