Object-Oriented Programming Basics
The problem
As data and the functions that operate on it grow more complex, keeping them as separate, loosely related pieces makes it easy to call a function with the wrong kind of data or to leave an object in an inconsistent state — bundling data and behavior together, with controlled access to the data, prevents whole categories of that misuse.
Why now
Types and values already established that data has a type with valid operations; functions and scope already established hiding internals as the default. A class is those two ideas fused into one unit — a type that owns both its data and the only functions allowed to touch it directly — which is a stronger guarantee than a type and a function living separately with no enforced connection.
Mental model
A class is a blueprint; an object is one instance built from it, with its own copy of the data (state) but sharing the blueprint's behavior (methods). Encapsulation is functions-and-scope's hide-by-default principle applied to an object's fields — only the object's own methods can touch its private data directly, so every other piece of code has to go through a controlled interface instead of reaching in.
Requires
- Types & ValuesProgramming Fundamentals
A class defines a new, compound type; you need the concept of a type as a set of valid values and operations before a class — a type you define yourself — makes sense.
- Functions & ScopeProgramming Fundamentals
A method is a function scoped to and operating on an object's own data; encapsulation is the same hide-by-default scoping principle already covered, applied to an object's fields instead of a function's local variables.
Unlocks
Used in
- Every object-oriented language's class/object model (Java, C#, Python, TypeScript)
- API design — a well-encapsulated class exposes a narrow, safe interface instead of raw internal fields
- Modeling real-world entities (a BankAccount, an Order) as objects with protected invariants
- The foundation every design pattern in this domain builds on
Projects
- Design a BankAccount class with private balance, and public deposit/withdraw methods that enforce balance never goes negative — then show that a caller cannot bypass those rules
- Take a set of loose functions operating on a shared data structure (e.g. plain objects representing a shopping cart) and refactor them into a class with encapsulated state
Examples
- A BankAccount class with a private balance field and public withdraw(amount) method can reject an overdraft inside the method — impossible to enforce if balance were a public field anyone could set directly
- getter/setter methods are the controlled doorway functions-and-scope's hiding principle requires when a private field's value still needs to be readable or changeable from outside
Resources
Mastery checklist
- I can explain the difference between a class and an object
- I can design a class with properly encapsulated (private) state and a controlled public interface
- I can explain why encapsulation prevents a category of bugs that public fields allow
- I can identify when a set of related functions and data should be modeled as a class