{"title":"OOP Basics","description":"","content":"Object-oriented programming is a way of organizing code around the data your program works with, instead of around the operations it performs. A `Product`, a `Cart`, an `Order`, each becomes a named type that bundles its own data with the functions that act on it. This lesson covers what OOP is, why it exists, the four ideas it's usually summarized by, and how Python in particular handles classes compared to languages with more ceremony.\n\n---\n\n# Before Classes: The Procedural Style\n\nOne way to write a program: pick some data, define a set of functions that operate on it, and call those functions in order. That style is called **procedural programming**. It works for short scripts, and it's how most of the code we've written so far has been structured.\n\nA small shopping cart written procedurally:\n\n\n```python\ndef make_cart(customer_name):\n return {\"customer\": customer_name, \"items\": [], \"total\": 0.0}\n\ndef add_item(cart, item, price):\n cart[\"items\"].append(item)\n cart[\"total\"] = cart[\"total\"] + price\n\ndef remove_item(cart, item, price):\n cart[\"items\"].remove(item)\n cart[\"total\"] = cart[\"total\"] - price\n\ndef show_cart(cart):\n print(f\"{cart['customer']}'s cart:\")\n for item in cart[\"items\"]:\n print(f\" - {item}\")\n print(f\"Total: ${cart['total']:.2f}\")\n\ncart = make_cart(\"Alice\")\nadd_item(cart, \"Wireless Mouse\", 29.99)\nadd_item(cart, \"Mechanical Keyboard\", 89.99)\nshow_cart(cart)\n```\n\n\nNothing is wrong with this code. It runs, it works, and a small program could be built this way. The data is a dictionary, the functions take that dictionary as their first argument, and the program is the sequence of calls at the bottom.\n\nThe trouble starts when the program grows. The functions `add_item`, `remove_item`, `show_cart`, and a dozen others (`apply_discount`, `merge_carts`, `clear_cart`, `count_items`) all need to live somewhere. They all take a cart as their first argument. They all know the shape of the cart dictionary (which keys it has, what types those values are). And nothing in the language ties them together. The `make_cart` function is defined on line 1, `show_cart` on line 80, and `clear_cart` in a different file. The only link is that the programmer remembers they all operate on the same kind of dict.\n\nIf a teammate changes the cart dict to use `\"total_amount\"` instead of `\"total\"`, every function has to be updated to match. The compiler can't help, because as far as Python is concerned, it's all just dictionaries.\n\n---\n\n# Bundling Data and Behavior\n\nObject-oriented programming says: take the data and the functions that operate on it, and group them into a single named type. A cart isn't a dictionary plus a pile of loose functions; it's one thing called a `Cart`, and the functions that work on it are part of that thing.\n\nThe same example, written with a class:\n\n\n```python\nclass Cart:\n def __init__(self, customer):\n self.customer = customer\n self.items = []\n self.total = 0.0\n\n def add_item(self, item, price):\n self.items.append(item)\n self.total = self.total + price\n\n def remove_item(self, item, price):\n self.items.remove(item)\n self.total = self.total - price\n\n def show(self):\n print(f\"{self.customer}'s cart:\")\n for item in self.items:\n print(f\" - {item}\")\n print(f\"Total: ${self.total:.2f}\")\n\ncart = Cart(\"Alice\")\ncart.add_item(\"Wireless Mouse\", 29.99)\ncart.add_item(\"Mechanical Keyboard\", 89.99)\ncart.show()\n```\n\n\nThe output is identical. The structure is not. The data (`customer`, `items`, `total`) and the operations (`add_item`, `remove_item`, `show`) are now defined together inside the `Cart` class. The call site reads as `cart.add_item(...)` instead of `add_item(cart, ...)`. The cart and its operations are one unit, not a dict plus a folder of related functions.\n\nThe mechanics are the same: there's still data, there are still functions, and the functions still take the data as their first argument (now called `self` instead of `cart`). What's different is the **grouping**. Reading the class shows, in one place, everything a cart is and everything a cart can do. The procedural version requires searching for every function that touches a cart dict.\n\nThe next few sections stay at the conceptual level: why this grouping matters, what problems it solves, and the four ideas common to OOP.\n\n---\n\n# State and Behavior, Together\n\nThe term commonly used in OOP is **state**. State is the data an object carries: the customer name, the list of items, the running total. Each cart in your program has its own state, separate from every other cart's. Two `Cart` objects can have the same items by coincidence, but they don't share storage; mutating one doesn't touch the other.\n\n**Behavior** is the set of operations that act on that state: adding an item, removing an item, computing a discount, showing the cart. In a class, behavior is expressed as methods, which are functions that live on the class and receive the instance as their first argument.\n\nCombining state and behavior into one named type gives several practical wins:\n\n- **Code colocates.** Everything a cart does is in the `Cart` class. No need to search across files for all the cart-related functions.\n- **Names get cleaner.** `cart.add_item(\"Mouse\", 29.99)` reads better than `add_item_to_cart(cart, \"Mouse\", 29.99)`. The cart is in the dotted call, so the function name doesn't have to spell it out.\n- **The shape of the data is documented.** Reading the `__init__` of `Cart` shows, in one glance, which attributes a cart has. No need to infer them by reading every function that pokes at the dict.\n- **Mistakes get harder.** A function that expects a `Cart` and gets a `Product` raises an `AttributeError` the moment it tries to call something the `Product` doesn't have. Dictionaries are duck-shaped; classes have a clearer signal of \"this is the wrong thing\".\n\nThese are small ergonomic wins that compound as the codebase grows. A 50-line script doesn't need any of them. A 5,000-line app does.\n\n---\n\n# The Four Pillars (At a Glance)\n\nMost OOP introductions list four ideas that show up in nearly every object-oriented language: encapsulation, inheritance, polymorphism, and abstraction. This section sketches each at a high level to introduce the vocabulary.\n\n\n```mermaid\nflowchart LR\n OOP[Object-Oriented
Programming]:::cyan\n\n ENC[Encapsulation
data + behavior
in one type]:::orange\n INH[Inheritance
reuse via
subclasses]:::green\n POL[Polymorphism
one interface,
many shapes]:::teal\n ABS[Abstraction
hide details,
expose intent]:::red\n\n OOP --> ENC\n OOP --> INH\n OOP --> POL\n OOP --> ABS\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram shows the four ideas as branches off the OOP trunk. They aren't a checklist to \"complete\" when writing a class; they're lenses for thinking about how code is organized. A class can use all four, or mostly one, depending on what it's modeling.\n\n### Encapsulation\n\nEncapsulation is the bundling described above: data and the functions that act on it live together in a single type. A `Cart` adds items to itself because the `add_item` method is part of the `Cart` class, not a separate function. The state (`items`, `total`) and the behavior (`add_item`, `remove_item`) are encapsulated inside the class.\n\nThere's a second piece to encapsulation: **hiding internal details**. Code outside the class should call methods like `cart.add_item(\"Mouse\", 29.99)` rather than reach in to mutate `cart.total` by hand. The internals are the class's business; the external surface is the methods it offers. Python is relaxed about enforcing this (there are no truly private attributes), but the convention of accessing state through methods is the standard way to write Python classes.\n\n### Inheritance\n\nInheritance lets one class build on another. Given a `Product` class with `name`, `price`, and `apply_discount`, and a need for a `DigitalProduct` with all of those plus a `download_url`, the solution is not to copy the `Product` code; `DigitalProduct` inherits from `Product`. The subclass gets everything the parent has, plus whatever extra it adds.\n\nA sketch:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nclass DigitalProduct(Product):\n def __init__(self, name, price, download_url):\n super().__init__(name, price)\n self.download_url = download_url\n```\n\n\n`DigitalProduct` inherits from `Product`, so every `DigitalProduct` instance has a `name` and a `price` automatically. Inheritance fits genuine \"is-a\" relationships (a digital product **is** a product) but is easy to overuse for \"kind of similar to\" relationships.\n\n### Polymorphism\n\nPolymorphism is the idea that different types can be used through the same interface. If a `Cart` calls `.price` on whatever it's holding, it doesn't care whether each item is a `PhysicalProduct`, a `DigitalProduct`, or a `Subscription`, as long as each one has a `price` attribute. The cart works with all three through the same code path.\n\nIn Python, polymorphism is often informal. There's no declaration that two classes \"implement the same interface\"; give them the same method names and attributes, and code that uses those names works with either type. That style has a name (duck typing) and a saying that goes with it: \"if it walks like a duck and quacks like a duck, it's a duck.\"\n\n### Abstraction\n\nAbstraction is closely tied to encapsulation, but it's about what the class **exposes**, not just what it **bundles**. A good class hides the details of how something works and gives callers a clean, intent-revealing interface. The caller knows what the class does, not how.\n\nA `Cart` with a method `apply_discount(percent)` is abstracting away the math. The caller says \"apply 10%\" and the method works out the rest. The caller doesn't need to know that the implementation iterates the items list and multiplies each price (or adjusts the running total once). That implementation could change tomorrow and the caller wouldn't notice, as long as `apply_discount(percent)` still does what its name promises.\n\nThat's the list. Encapsulation, inheritance, polymorphism, abstraction. The names are what to recognize.\n\n---\n\n# Why Use Classes at All?\n\nNot every program needs classes. Plenty of useful Python code (scripts, small utilities, single-file tools) gets along with functions and built-in types. Using a class because \"real Python has classes\" is the wrong reason. So when is a class the right choice?\n\nSignals that a class will help:\n\n- **Multiple values move together.** If a customer is always represented by name plus email plus address plus a list of past orders, those four pieces are really one thing, and a class makes that explicit. Passing them as separate arguments to every function is tedious and error-prone.\n- **State changes over time.** A cart accumulates items, an order moves through statuses (placed, shipped, delivered), a session tracks the current user. Anything with a lifecycle benefits from an object that holds the state and provides methods to transition it.\n- **The same operations apply to many similar things.** When creating thousands of products, each with the same shape and the same operations (`apply_discount`, `is_in_stock`, `format_price`), a `Product` class lets those operations be written once and applied to every instance.\n- **Enforcing rules.** If a `Review` rating must be between 1 and 5, putting the validation in `__init__` means no `Review` instance can exist with an invalid rating. The class is a gatekeeper. Achieving the same thing with a dict means scattering checks across every function that creates or modifies a review.\n- **Extension later.** With a `Product` today and a possible `DigitalProduct` or `SubscriptionProduct` tomorrow, starting with a class makes the extension obvious. Starting with a dict makes it a rewrite.\n\nAnd when functions and built-ins are enough:\n\n- **Stateless operations.** A function that takes a string and returns a slugified version doesn't need to be a method on a class. Wrapping it in a `Slugifier` class with a single method is ceremony for ceremony's sake.\n- **One-off scripts.** A 30-line script that reads a CSV, computes a sum, and prints it doesn't need a class. Use what fits.\n- **Functional pipelines.** If the work is mostly transforming data through a chain of pure functions (map, filter, reduce style), functions and built-in types often read more clearly than classes.\n\nThe rule of thumb: use a class when the alternative is passing the same three or four values to every function in a group, or when something has its own lifecycle that needs tracking. If neither is true, functions are usually fine. Python is unusual among \"OOP languages\" in not forcing classes for everything; use that flexibility.\n\nA class has a small runtime overhead compared to a plain dictionary: attribute lookups go through more layers, and instances carry a reference to their class. For most code, this doesn't matter. When storing millions of small records, libraries like `dataclasses` (with `slots=True`) or `typing.NamedTuple` give class-like syntax with leaner storage.\n\n---\n\n# Python's Take on OOP\n\nDifferent languages do OOP differently, and Python's flavor has a particular character. Coming from another language, some of Python's choices may seem unusual; for Python as a first language, knowing these choices helps when reading about OOP elsewhere where other languages are stricter.\n\n### Everything Is an Object\n\nIn Python, **every value is an object**. Integers, strings, lists, functions, classes themselves: all of them are objects with a class, attributes, and methods. There is no distinction between \"primitive types\" (which can't have methods) and \"object types\" (which can) the way there is in some languages.\n\n\n```python\n>>> (42).bit_length()\n6\n>>> \"hello\".upper()\n'HELLO'\n>>> [1, 2, 3].count(2)\n1\n>>> type(42)\n\n>>> type(\"hello\")\n\n>>> type(print)\n\n```\n\n\nEvery one of those values has a class, and methods can be called on all of them. Functions are objects too: they can be passed as arguments, stored in lists, and have attributes attached to them. That uniformity makes Python's object model consistent. User-defined classes sit alongside the built-in types, and operators like `+`, comparison, indexing, and iteration all work through the same mechanism (dunder methods).\n\n### Duck Typing Over Strict Interfaces\n\nIn languages like Java or C#, polymorphism is usually expressed through interfaces or abstract base classes that types must explicitly declare they implement. Python prefers the lighter approach: if an object has the right methods and attributes, it works in any place that calls those methods, regardless of its class.\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nclass Subscription:\n def __init__(self, name, monthly_fee):\n self.name = name\n self.price = monthly_fee # same attribute name on purpose\n\ndef cart_total(items):\n return sum(item.price for item in items)\n\ncart = [Product(\"Mouse\", 29.99), Subscription(\"Pro Plan\", 9.99)]\nprint(f\"Total: ${cart_total(cart):.2f}\")\n```\n\n\n`cart_total` doesn't know or care that the list mixes two different classes. It reads `.price` off each item. As long as every item has a `.price` attribute, the function works. That's duck typing, and it's how most polymorphism is expressed in Python.\n\nThere's a trade-off. The flexibility is genuine: a new \"cart-able\" type can be added without inheriting from a common base or formally implementing an interface. The downside is that the connection between `cart_total` and the types it works with isn't declared anywhere. A reader has to work it out from the code. Python's type hints (`item: Product`, or `Protocol` from `typing`) help fill that gap when the implicit contract is worth making explicit.\n\n### Less Ceremony Than Java or C++\n\nPython's class syntax is shorter than most. There are no field declarations at the top of the class, no separate header file, no required getters and setters, no mandatory access modifiers, no curly braces. A useful Python class can be three lines:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n```\n\n\nThe same class in Java is several times as long once the field declarations, the constructor, the getters and setters, and the package boilerplate are written. None of that extra code does anything Python's three lines don't already cover.\n\nThis is a deliberate language choice. Python optimizes for **readability and short programs**. The trade-off is that some things other languages enforce at compile time (private fields, type safety, abstract methods that subclasses must implement) Python enforces by convention, by runtime checks, or not at all. Python's tools for those include the `_` prefix convention for \"private\", `@property` for controlled access, and `ABC` for required methods.\n\n### Multiple Inheritance Exists, Use Sparingly\n\nPython allows a class to inherit from more than one parent, a feature some other languages restrict or forbid. The flexibility is occasionally useful but easy to abuse. The **method resolution order** determines which parent's method wins when more than one defines the same name. The headline: Python allows it, but most Python code uses single inheritance, and many designs that look like they \"need\" multiple inheritance are cleaner with composition (one class holding instances of others as attributes).\n\n\n```mermaid\nflowchart TD\n Java[Java / C++
strict, verbose,
compile-time checks]:::orange\n Python[Python
flexible, terse,
runtime checks]:::cyan\n JS[JavaScript
prototype-based,
very flexible]:::teal\n\n Java --> Style[OOP Style]:::green\n Python --> Style\n JS --> Style\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram is a rough placement, not a strict ranking. Different languages occupy different points on the trade-off curve between \"the compiler catches everything\" and \"the programmer has the flexibility to do whatever.\" Python sits closer to the flexible end than Java or C++ but not as far as JavaScript. Knowing where Python sits helps when reading code in another language and noticing it looks heavier; that's not Python being lax, it's the other language enforcing things at a different point in the design.\n\n---\n\n# A Real Python Class\n\nA class that combines the mechanics: defining a class, creating instances, setting them up with `__init__`, attributes (instance vs class), methods, and special \"dunder\" methods that integrate classes with operators and built-ins.\n\n\n```python\nclass Product:\n tax_rate = 0.08 # class attribute, shared by every product\n\n def __init__(self, name, price, stock=0):\n self.name = name\n self.price = price\n self.stock = stock\n\n def total_price(self):\n return self.price * (1 + self.tax_rate)\n\n def restock(self, quantity):\n self.stock = self.stock + quantity\n\n def __repr__(self):\n return f\"Product({self.name!r}, ${self.price})\"\n\nmouse = Product(\"Wireless Mouse\", 29.99, stock=50)\nmouse.restock(10)\nprint(mouse)\nprint(f\"With tax: ${mouse.total_price():.2f}\")\n```\n\n\nThere's a class attribute, an `__init__`, two regular methods, and one dunder method (`__repr__`) that hooks into `print`. This is what a \"real\" Python class looks like in Pythonic style.","pageType":"python"}

OOP Basics

Get Premium