OOD Foundations

📘 Learn OOD Foundations from zero

Start from zero. Object-oriented design (OOD) is a way of writing software by bundling data and the behavior that acts on that data into single units called objects. A class is the blueprint; an object is one built thing from that blueprint.

Analogy: a coffee shop. The recipe card for a latte is a class — it lists ingredients (attributes: size, milkType) and steps (methods: brew(), steamMilk()). Each actual latte handed to a customer is an object. The four pillars: Encapsulation (bundle the data with its methods and lock down direct access — the espresso machine exposes a button, not its boiler valves) — Abstraction (model only the essentials, hide the rest — you order "a latte," not "92C water through 18g of grounds") — Inheritance (a FlavoredLatte is-a Latte with extra syrup) — Polymorphism (every drink exposes prepare(), but each implements it its own way).

Worked example — model a parking lot. Extract nouns as classes: ParkingLot, ParkingSpot, Vehicle, Ticket. Extract verbs as methods: park, unpark, calculate fee. Relationships: a ParkingLot is composed of ParkingSpots — a spot has no meaning once its lot is gone, so this is composition (filled diamond on the lot). Car and Truck are Vehicles — that is inheritance. UML (Unified Modeling Language) is just the standard picture language to draw this: a class diagram for the structure above, and a sequence diagram to show Customer → Entrance → assignSpot() → issueTicket() in call order.

Key insight: good OOD comes from assigning each responsibility to exactly one class so things are highly cohesive (each class does one job well) and loosely coupled (classes depend on each other as little as possible).

✨ Added by the guide to build intuition — not from the source course.

🎯 Guided practice

1. Easy — Model a Library book checkout. Goal: produce a class diagram and identify relationships.
   1. Extract nouns from the prompt: "A member borrows a book from the library and gets a loan record." Candidate classes: Member, Book, Library, Loan.
   2. Extract verbs as methods: borrow, return → Library.checkout(member, book), Library.returnBook(loan).
   3. Assign attributes by asking "what does each thing know about itself?" Book: title, isbn, isAvailable. Member: memberId, name. Loan: dueDate, links one Member to one Book.
   4. Decide relationships — and get composition vs aggregation right. A Library has-many Books, but a book exists independently of any one library, so this is aggregation (hollow diamond), not composition. Contrast with the parking lot, where spots die with the lot (composition, filled diamond): the test is lifecycle ownership. Loan associates exactly one Member with one Book — and it is its own class precisely because the relationship carries data (dueDate). Pattern learned: when a relationship itself carries data, promote it to a class (an association class).
2. Medium — Model a vending machine and show its behavior. Goal: pick the right diagram for each question and apply polymorphism.
   1. Structure first (class diagram): VendingMachine, Product, Inventory, Payment. Make Payment an abstract base with CashPayment and CardPayment subclasses, each overriding process() — that is polymorphism: the machine calls payment.process() without knowing the concrete type. This keeps the machine loosely coupled to payment methods and open to adding new ones without editing existing code — the SOLID Open/Closed principle.
   2. Interaction over time (sequence diagram): Customer → VendingMachine.selectProduct() → VendingMachine → Inventory.check() → VendingMachine → Payment.process() → VendingMachine → dispense(). Choose a sequence diagram because the order of messages between objects is the point.
   3. Two ways to model the dynamics — and they are different diagrams. If you frame the machine as the states it sits in — Idle → ProductSelected → AwaitingPayment → Dispensing → Idle, with the transition "payment valid?" falling back to AwaitingPayment on failure — that is a state machine diagram (states + triggered transitions). If instead you frame it as the flow of actions a transaction performs, with a decision node and a loop on retry, that is an activity diagram. Use whichever the interviewer asks for, but do not call a state-named flow an "activity diagram" — that is the classic mislabel.
   4. Why this is the FAANG bar: you separated static structure (class diagram), interaction (sequence diagram), and dynamics (state machine or activity diagram), and used abstraction + polymorphism to make payment extensible. The reusable recipe: nouns → classes, verbs → methods, "varies by type" → abstract base + subclasses, "order of calls matters" → sequence, "branching workflow" → activity, "object moves through states" → state machine.

✨ Added by the guide — work these before the full problem set.