OOP: What Is Object-Oriented Programming

Picture writing software that keeps track of a school: students, courses, grades. You could keep everything in separate lists of numbers and text, or you could group each student’s data together with the actions that involve them: enrolling in a course, receiving a grade. The second approach is object-oriented programming, OOP: a programming style that organizes code around objects, units that hold data and functions together instead of keeping them apart. It’s a way of thinking found across many languages, including JavaScript, TypeScript, Java, Python, and C++, though it isn’t the only one.

An object is data plus behavior

In the official Java documentation, a software object holds its own state in fields (the variables that belong to it) and exposes its behavior through methods, functions that act on that state. Methods are also how one object talks to another: when two objects work together, they usually do it by calling each other’s methods, not by reading each other’s data directly.

That idea isn’t far from how objects in the physical world get described: a bicycle has state (the gear it’s currently in, its speed) and behavior (braking, shifting gears). Carrying that same structure over into code is where OOP starts.

The class is the blueprint, the object is the item built

An object doesn’t come from nowhere: it comes from a class, which the Java documentation describes as the blueprint individual objects are created from. The class sets which fields and methods every object built from it will have; the object itself, once created, is called an instance of that class.

Practical example: picture a Bicycle class. It defines that every bicycle has state (its current gear) and behavior (shifting gears). Every individual bicycle built from that blueprint, with its own gear set at a given moment, is an instance of the Bicycle class — same blueprint, different objects.

Encapsulation: hiding state, not code

The first of the concepts the Java documentation ties to OOP is encapsulation: hiding an object’s internal state and requiring that every interaction with it pass through its methods. It isn’t, as people often assume, a form of secrecy over source code; it’s a way of keeping what an object does separate from how it does it internally, so the rest of the program can use it without worrying about its inner details. The MDN documentation gives a similar definition: keeping an object’s internal state private, with a clear line between its public interface and its private data, is what’s called encapsulation.

Inheritance: reusing without rewriting

OOP lets one class inherit shared state and behavior from another. In the Java documentation’s example, a MountainBike class can inherit every field and method from a more general Bicycle class, so its own code focuses only on what makes it different, such as suspension. The result, according to the same source, is code that’s easier to read: nothing that’s already written in Bicycle needs repeating in MountainBike.

The official Python documentation confirms inheritance as a standard OOP feature too, with its own mechanics: a derived class can override any method of its base class, and a method in the base class can end up calling — without knowing it — the redefined version in the subclass.

Polymorphism: same name, different behavior

When a method has the same name but a different implementation across classes, the MDN documentation calls that feature polymorphism. It typically shows up when a subclass overrides an implementation inherited from a higher-level class — for instance, when a MountainBike handles gear shifting differently from a general Bicycle despite sharing the same method name.

Worth stating plainly: the MDN documentation organizes the whole topic around three main concepts — classes and instances, inheritance, encapsulation — and presents polymorphism as an effect of inheritance rather than a separate pillar. That’s one reason this Recap notes, further on, that not every technical source lists OOP’s concepts the same way.

Abstraction: defining the what, leaving the how to subtypes

The Java documentation also describes abstract classes: a class declared abstract can’t be turned directly into an object, but it can be subclassed. It can hold abstract methods, declared without an implementation — a requirement, not a suggestion, since every concrete subclass has to supply its own.

The same source’s example is an abstract GraphicObject class: every graphic object must be able to draw and resize itself, but each type does it its own way, a circle one way, a rectangle another. The abstract class captures what they share, the what, and leaves each subclass to work out the how. This separation between a common interface and the details of implementation is what the sources call abstraction.

An idea built to simulate the world, not to write it

OOP’s roots, according to the historical marker from the IEEE Engineering and Technology History Wiki, go back to 1961, when Ole-Johan Dahl and Kristen Nygaard began working together at the Norwegian Computer Center on a language for describing computer simulations. Their result, Simula 67, was completed in 1967 and introduced encapsulation, inheritance, late binding of methods, and dynamic object creation together — the elements now considered essential to an object-oriented language. The idea of an “object” didn’t start out as a way to write software in general; it started as a way to model complex systems, such as waiting lines or traffic.

More than thirty years after that work, Dahl and Nygaard received the Turing Award, computing’s top honor, often compared to a Nobel Prize for the field, specifically for the ideas behind Simula I and Simula 67.

Four pillars? Sources don’t fully agree

Classrooms and textbooks often describe OOP as resting on four pillars: encapsulation, inheritance, polymorphism, and abstraction. It’s a useful teaching arrangement, but not a canon every technical source agrees on the same way: the MDN documentation, as noted above, lists three and treats polymorphism as a consequence of inheritance; other sources, like the Java page on abstract classes, cover abstraction on its own page without slotting it into a numbered list of pillars. Knowing this distinction helps avoid presenting as a fixed fact what is, in practice, one of several ways to organize the same set of ideas.

Concept	What it does	Conceptual example
Encapsulation	Hides internal state, forces methods to be used	A bicycle: you shift gears with the lever, not by touching the gears themselves
Inheritance	Lets one class inherit state and behavior from another	MountainBike inherits from Bicycle and adds suspension
Polymorphism	Same method, different implementation per class	MountainBike shifts gears differently from Bicycle
Abstraction	Defines a shared interface, leaves details to subtypes	GraphicObject requires “draw itself,” each shape does it its own way

These concepts don’t belong to a single language. The history of computers shows how programming languages evolved through different styles over time; today OOP sits alongside other approaches, and how a program applies it also depends on what the program needs to do — process data bound for a relational database, say, or run an algorithm for a calculation. The official Python documentation confirms that the same concepts, multiple inheritance included, show up in a language with syntax very different from Java’s.