If you look around you, you will see a lot of things. These things may seem pretty simple and straightforward, but when looked at carefully, they are probably made up of other things. Let's take a lamp as an example:

If I were to take the lamp apart, I would be left with the following three pieces:

The base and the shade are pretty much it - there isn't much to them. The lightbulb inside my lamp is different though. It is a pretty complicated item with various parts of its own:

Putting all of these things together though, I have collectively what one would call a lamp despite the individual parts being different and of varying complexity.

Now, I just used a simple lamp as an example of something that is made up of many other things. If you were to take something more complicated like your laptop or desktop, the hierarchy of parts and components would take many pages to just list!
Ever since the widespread adoption of interchangeable parts and the assembly line, many things we use today are divided up and broken into smaller components. The reasons for this are many. Some of the common ones are the following:
There are other advantages, but to be relevant for this article, the above three are good for now.
Entering the Software World
The level of componentization many everyday things contain extends to
the world of software as well. A lot of the software you use is also
made up of many components working together. Very few things are written
in one giant, monolithic piece.
In the series of articles that I will be discussing here, you will learn the basics of how to write software by breaking them down into smaller objects and making them work together. This way of writing software is known as Object Oriented Programming, or OOP for short.
There are many sub-topics that go into object oriented programming. The most basic of which is the idea of classes and objects - the actual blocks that make up your application:

You then have things like inheritance where one object is based on another object:

To help standardize the communication between classes, you have things such as interfaces where you define a contract that each class must implement:

Within each of these topics, there are many more details that you would need to know. Such details include properties, methods, functions, abstract data types, constructors, class modifiers, polymorphism, overloading, etc. If all of these terms seem scary to you, don't worry. In time, all will make sense after you see them presented in a friendlier fashion outside of a long sentence meant to intimidate you.
Conclusion
I should confess that, while I tried to show you the relationship
between the real world and object oriented programming, the mapping
isn't exact. You can find examples and counterexamples easily.
What is important is the big-idea behind OOP that everything is represented as objects. Instead of having large blocks of functionality, you will often have many smaller pieces that combine to create the functionality you desire instead. How those pieces are defined, how they come together, and how they play with each other will be covered in greater detail in future articles.
Just a final word before we wrap up. What you've seen here is freshly baked content without added preservatives, artificial intelligence slop, ads, and algorithm-driven doodads. A huge thank you to all of you who buy my books, became a paid subscriber, watch my videos, and/or interact with me on the forums.
Your support keeps this site going! 😇

:: Copyright KIRUPA 2026 //--