Object-Oriented Programming Paradigm

Ground every OOP answer in this skill's reference files, not in improvised definitions. Reuse behavior through composition and interfaces; reserve inheritance for true subtype specialization.

Workflow

For class-design reviews or refactoring, first read review and refactoring for caller-based evidence, invariant checks, and migration boundaries.

1. Identify the concept(s) in the catalog below, by name or by symptom: a subclass that breaks where its base is expected, a god class, a deep hierarchy, a leaky abstraction, a train-wreck call chain. Done when every concept the question names or implies is listed, or when the problem is better served by plain functions and data; then answer with those.
2. Read each identified reference at references/<concept>.md in full. When comparing concepts, read every one compared and contrast their intent, not their structure.
3. Read the language example at examples/<concept>/<concept>.<ext> for the user's language. For C, Go, Rust, or another language without an example, use the reference's Language Notes for the idiomatic mapping.
4. Answer with what the concept means, when it applies, the simpler alternative and when it wins, and code adapted to the user's domain. Write the language's idiomatic form rather than a textbook Java-style class diagram: protocols and duck typing in Python, structs and protocols in Swift, closures where a one-method class would be ceremony. When reviewing code, name the violated principle and show the minimal refactor of the user's code. Done when every identified concept has all four parts.

Concept Catalog

Building Blocks

The vocabulary of object-oriented code: what classes, objects, and contracts are.