What is "Mental Models" about?

Master the mental shift from imperative logic to object-oriented abstraction.

What topics does "Mental Models" cover?

This article covers: abstraction, oop, mental models, lld, design thinking.

Mental Models

In the world of professional software development, the way you think about code is more important than the language you write it in. When you look at a problem, do you see a list of instructions, or do you see a set of living, breathing ideas?

This shift in perspective is the difference between a beginner and a master. Let's explore the two dominant mental models and why one of them is the core principle behind almost every major application on the planet.

The Essentials

Before we dive into the "How", here are the "Core Concepts" to remember:

Action vs Thing: Functional programming focuses on the Action, while OOP focuses on the Thing.
The Steering Wheel: Abstraction allows you to use a complex system by interacting with a simple summary.
Natural Language: OOP is successful because it mirrors how human language organizes the world into Subjects and Actions.
Blueprint vs Instance: A Class is the blueprint (Idea), while an Object is the instance (Body).

1. The "Action First" Way (Procedural Thinking)

In the early days of programming, we built everything around Functions. A function is essentially a "boss" that takes some passive data, performs an action on it, and outputs a result. We call this Procedural Programming.

Imagine you have a student's name and age. In a procedural system, the code would look like this:

Mental Models in Action: The Thinking Problem

Action First (Procedural)

Data is just a bag of variables on a table. The "Boss" (function) takes it and processes it. Anyone can mess with the bag.

let age = 25;
function updateAge(a) { .. }

// Any function can touch 'age'

Hard to track who changed what. This is the "Chaos World" of passive data.

Passive Data Chaos

✓

Thing First (OOP)

The "Idea" (Object) owns its data and its actions. You don't "touch" the data; you ask the object to perform an action.

class Student {
  private age = 25;
  celebrateBirthday() {
    this.age++;
  }
}

The object is responsible for itself. This mirrors how humans actually think and speak.

Self-Responsible Objects

Code Implementation: Shifting the Focus

Here is how the same logic looks when we shift from making the function the boss to making the "Thing" the owner:

// PROCEDURAL: The function is the boss
function printStudentDetails(name: string, age: number) {
    console.log(`Student: ${name}, Age: ${age}`);
}

// OOP: The Student is the boss
class Student {
    constructor(private name: string, private age: number) {}

    printDetails() {
        console.log(`Student: ${this.name}, Age: ${this.age}`);
    }
}

const s = new Student("Durgesh", 25);
s.printDetails(); // "Hey Student, perform your action."

It looks like a small change, but the mental model is revolutionary:

Procedural: "Hey computer, take this data and do something to it."
OOP: "Hey Student, perform your action."

In the next post, we'll explore Access Modifiers in depth and learn how to hide the "internal circuits" of our objects.

Abstraction: The Principle of Ideas

Abstraction is more than a tool: it is the Goal.

ExpandOOP: One Principle (Abstraction) supported by three pillars

Identifying "Ideas" (Entities)

How do you find these "Ideas" in a messy real-world problem? An Idea (also called an Entity or Noun) is anything that does one of these three things:

Causes Behavior: It can act (like an Instructor teaching a class).
Stores Information: We need to remember things about it (like a Student's PSP).
Participates in Action: It is involved in the system's workflow (like an Assignment submission).

The Sanskrit Connection: Guna and Karma

It's fascinating to note that these "Modern" OOP concepts have roots in ancient linguistics. In Sanskrit, every noun is defined by its Guna (Properties/Attributes) and its Karma (Actions/Behavior).

When you define a Student class with name (Guna) and changeBatch() (Karma), you are following a mental model that is thousands of years old. This is why OOP feels so "right": it isn't just a coding trick; it's a reflection of how human language and thought have always organized the universe.

Why Abstraction Wins: The Steering Wheel Example

Think about the last time you used a car. To turn left, you simply turned the steering wheel left.

Focus on "What": You interact with a "Summary" of the car's actions without knowing the internal gears.
Natural Language: Every human language is built on a Subject performing an Action.

By building your software around Ideas and Abstraction, you ensure that no matter how complex the system becomes, it remains understandable, maintainable, and human.

In the next chapter, we'll dive into the first pillar of OOP: Encapsulation, and learn how to protect these ideas from a chaotic world.