DEV Community

Understanding Object-Oriented Programming (OOP) in JavaScript

henry messiah tmt on September 13, 2025

Introduction Programming is much like building a city. You don’t throw bricks, cement, and metal randomly together, instead you carefull...

Read full post

ADIKA DAVID • Sep 13

Great write-up, Henry! The real-world analogies (especially the car system example) made the OOP concepts much clearer and relatable. I also like how you broke down encapsulation, abstraction, inheritance, and polymorphism in a beginner-friendly way. This will definitely help a lot of learners approach JavaScript OOP with more confidence. Looking forward to more tutorials from you. Cheers

henry messiah tmt • Sep 13

Thank you very much

ADIKA DAVID • Sep 13

Great write-up, Henry! 👏
The real-world analogies (especially the car system example) made the OOP concepts much clearer and relatable. I also like how you broke down encapsulation, abstraction, inheritance, and polymorphism in a beginner-friendly way. This will definitely help a lot of learners approach JavaScript OOP with more confidence. Looking forward to more tutorials from you. Cheers

henry messiah tmt • Sep 13 • Edited

Thanks a lot

Dr Mark • Sep 13

This is the best OOP in JavaScript article I’ve ever seen. This article is both enthralling as well as educative with key concepts well explained in a simplified manner. Thanks for sharing this great piece

henry messiah tmt • Sep 13

Thank you very much

EBIWENI LOKOJA • Sep 13

When it comes to programming nobody does it better.
Thank you for the eye opener.
I'm learning every day

henry messiah tmt • Sep 13

Thanks for the nice comments

Justin Ikakah • Sep 13

Great piece of work

henry messiah tmt • Sep 13

Thanks

Alexander Ogbu • Sep 13

I always look forward to reading great write-up from this fellow. Keep up the good work. Cheers

henry messiah tmt • Sep 14

Thank you very much

Ebiasuode felix konyefa • Sep 13

Very impressive and carefully written…
👍👍

henry messiah tmt • Sep 13

Thanks

Richard Ben • Sep 13

Very interesting write up, thanks for sharing Henry.

henry messiah tmt • Sep 13

Thanks man

Samuel Rouse • Sep 15

Thanks for posting this! While I mostly recommend against OOP in JavaScript, I think it's an important paradigm to understand.

I think your Abstraction section isn't ideal. The way you define _balance and the related methods inside the constructor mixes actual OOP with closures. The getBalance and deposit methods are not members of the class this way, they are redefined for each instance.

This was how we managed private values prior to ES2022 when Private elements were added to the spec.

Using the private elements simplifies the design makes use of class-level methods.

// Abstraction example with a BankAccount class
class BankAccount {
  // Private variable to hold the balance
  // It cannot be accessed directly outside the class
  #balance

  constructor(owner, balance) {
    this.owner = owner; // account owner's name
    this.#balance = balance;
  }

  // Method to check current balance (controlled access)
  getBalance() {
    return this.#balance;
  }

  // Method to deposit money (changes balance internally)
  deposit(amount) {
    this.#balance += amount;
      console.log(`Deposited ${amount}. New balance: ${this.#balance}`);
  }
}

// Create a new bank account with an initial balance of 1000
const account = new BankAccount("Peace", 1000);

// Deposit money using the provided method
account.deposit(500); // Output: Deposited 500. New balance: 1500

// Access the balance safely through the method
console.log(account.getBalance()); // Output: 1500

// Direct access like account.#balance is not possible (hidden!)

sinni800 • Sep 14

Not the car analogy...

Also a lot of the "importances" are just really good weather sort of ideas. It does not guarantee reusability at all, for example, and with something like the "car analogy", it even guarantees that scalability will suffer. We should not model the code after the domain of the real world idea, but we should model it after the domain of concerns. Rather than making a car and "have the steering wheel take care of physics", make a physics class (or module). make subsystems that concern themselves with one technical concern, not with a domain concern.

Overall this article advertises the same tired way of doing things that has been making our applications slow and bad to maintain for a long time now. As a beginner of course someone would be impressed by it...

Uncle bob would be proud

what you should honestly do is watch this talk on the topic and maybe see what's going on youtu.be/wo84LFzx5nI