OOD Foundations — Capstone & Self-Check

OOD Foundations: What You Should Now Own

Before moving on, make sure the following ideas feel automatic rather than memorized. The rest of the OO & Low-Level Design course builds directly on them.

• Object vs. class: A class is the contract/blueprint; an object is a concrete instance with state and identity.
• The four pillars are consequences, not slogans: Encapsulation hides volatility, abstraction hides complexity, inheritance expresses "is-a," and polymorphism lets callers depend on behavior rather than concrete types.
• Composition over inheritance: Prefer assembling behaviors over subclassing for reuse. Inheritance is a strong coupling; use it when the "is-a" relationship is truly stable.
• Cohesion and coupling are the real goals: A class should have one focused reason to change and depend on as few concrete details as possible.
• UML is a communication tool, not a specification: Class diagrams show structure; sequence diagrams show collaboration. Use just enough notation to make a design review clear.

Where to Go Next

These next modules turn the foundations into interview-ready design judgment:

• SOLID Principles — Learn to recognize the five code smells and refactor toward each principle. This is where "good OO" becomes measurable.
• Design Patterns Overview — See the catalog of proven solutions, but more importantly learn when not to apply each one.
• OO Design Problems — Practice requirements-to-classes on canonical problems (parking lot, elevator, ticket booking, etc.).

Self-Check Drill

Answer these without peeking. If any answer feels shaky, revisit the corresponding lesson before continuing.

1. Give a concrete example where inheritance is the right choice and one where composition is the better choice.
2. What is the difference between cohesion and coupling? Which one does SRP directly improve?
3. Draw a class diagram for a PaymentProcessor that can handle CreditCard, PayPal, and BankTransfer without using three subclasses of the processor.
4. When would you choose an interface over an abstract class?
5. Name three signs that a class is violating encapsulation.

Sample answers (only after attempting the drill):

1. Inheritance: Square is-a Shape only if the LSP contract holds. The classic trap is Square extends Rectangle: it is a valid subtype only if clients never assume setWidth/setHeight change one dimension independently — because a square must keep them equal. When that assumption exists, model both as a Shape with fixed dimensions instead of subclassing. Composition: a Car has-an Engine; swapping engine types should not require a new Car subclass.
2. Cohesion is how related the responsibilities inside a single module are; coupling is how much modules depend on each other. SRP improves cohesion by keeping a class focused on one responsibility.
3. PaymentProcessor depends on a PaymentMethod interface. Each payment type implements the interface. The processor delegates to the injected method.
4. Use an interface when multiple unrelated classes must share a contract; use an abstract class only for true "is-a" with shared implementation.
5. Exposed mutable fields, getters that return internal mutable collections, and methods that reach deeply into another object's collaborators (Law of Demeter violation).

I just read a lesson on **OOD Foundations — Capstone & Self-Check** (OO & Low-Level Design) and want to truly understand it. Explain OOD Foundations — Capstone & Self-Check from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **OOD Foundations — Capstone & Self-Check** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **OOD Foundations — Capstone & Self-Check** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **OOD Foundations — Capstone & Self-Check** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.