How to Code in an Object-Oriented Way: Mindset, Habits & Practice

🧠 Mindset Shift #1: Stop Looking for Nouns, Start Finding Responsibilities

The classic beginner advice for OOP is: “Look at the problem description and underline the nouns. Those are your classes.” This is terrible advice. It leads to classes like DataManager and UtilityHelper—meaningless buckets of unrelated functions.

The better question: “What are the distinct responsibilities in this system?” A responsibility is a reason to change. If you can imagine two different reasons why a class might need to be modified, it has too many responsibilities.

🧠 Mindset Shift #2: Tell, Don’t Ask

Procedural code interrogates data: “Give me your state so I can make a decision for you.” Object-oriented code delegates: “Here’s a message. You handle it.”

Consider this procedural approach:

# Procedural: Asking for data, then acting on it
if user.get_account_status() == "active" and user.get_plan() == "premium":
    discount = user.get_loyalty_points() * 0.01
    apply_discount(discount)

Versus the object-oriented approach:

# Object-Oriented: Telling the object to handle itself
user.apply_premium_discount()

The second version trusts the User object to know its own rules. When the loyalty program changes next quarter, you change code in exactly one place. This is encapsulation at work—not just hiding data with private variables, but hiding decisions.

🧠 Mindset Shift #3: Prefer Composition Over Inheritance (But Know When to Use Both)

Inheritance is the first OOP concept everyone learns. It’s also the most overused and misapplied. Beginners create deep hierarchies: Animal → Mammal → Canine → Dog → GoldenRetriever. This feels satisfying until requirements change: “Wait, now we need a RobotDog that barks but doesn’t eat.”

The litmus test: Is this an “is-a” relationship that will never change? If you’re not certain, use composition (“has-a”).

class Bird:
    def fly(self):
        return "Flying"

class Penguin(Bird):
    def fly(self):
        raise NotImplementedError  # Uh oh.

class FlyingBehavior:
    def fly(self): return "Flying"

class Bird:
    def __init__(self, flying_behavior=None):
        self.flying = flying_behavior

penguin = Bird(flying_behavior=None)  # Solved.

Inheritance is for when you want to be bound to your parent’s contract. Composition is for when you want to use a capability. Most of the time, you want the latter.

🧠 Mindset Shift #4: Design from the Outside In

Beginners often start by writing the internal fields of a class: “Okay, a User has a name, email, password_hash…” Then they add methods as an afterthought. This produces data containers, not objects.

Coding object oriented means designing the interface first. Ask: “What messages should this object respond to?” Write the code you wish you had, then make it work.

# This is what you WISH you could write:
playlist = Playlist("Workout Mix")
playlist.add(Song("Eye of the Tiger"))
playlist.shuffle()
player = MusicPlayer()
player.load(playlist)
player.play()

🧠 Mindset Shift #5: Embrace Immutability (Where Practical)

Objects that change their internal state after creation are harder to reason about. You call order.process() and suddenly order.status is different. This is fine, but it requires you to track the lifecycle.

Many bugs come from objects being in unexpected states. A powerful pattern is to create new objects instead of mutating existing ones, especially for value types like Money, EmailAddress, or DateRange.

# Mutable (can lead to bugs if shared)
class ShoppingCart:
    def add_item(self, item):
        self.items.append(item)  # Modifies existing cart

# Immutable (safer, clearer)
class ShoppingCart:
    def add_item(self, item):
        new_items = self.items + [item]
        return ShoppingCart(new_items)  # Returns a NEW cart

This functional-influenced OOP style is common in modern languages like Kotlin and Scala, and increasingly in Python and Java. It makes testing and parallel processing dramatically easier.

• Day 1: Take a script you wrote months ago. Identify the longest function. Refactor it into a class with one clear responsibility.
• Day 2: In the same codebase, find three places where a dictionary is used to pass related data (user_data = {'name': ..., 'email': ...}). Replace each with a proper class.
• Day 3: Write a small program from scratch using TDD. Build a BankAccount with deposit, withdraw, and transfer methods. The transfer should involve two accounts.
• Day 4: Extend Day 3’s code. Add a SavingsAccount that inherits from BankAccount but limits withdrawals. Experience inheritance firsthand.
• Day 5: Now refactor. Remove the inheritance. Create a WithdrawalStrategy interface and use composition. Compare which design feels more flexible.
• Day 6: Find an open-source Python library on GitHub. Look at its class structure. Identify one design pattern you recognize. Read the discussion in the issues about why a certain class exists.
• Day 7: Design—don’t code—a system on paper or whiteboard. Model a library checkout system. Draw boxes for classes and arrows for relationships. Write the public methods for each class. Then explain it to someone (or a rubber duck).