By the time you reach this point in the series, you have already taught the computer how to remember things, make decisions, repeat itself with dignity, think algorithmically, organize data, survive debugging, solve problems by shrinking them, respect performance, manage memory, talk to the outside world, stay modular, tolerate tests, and misbehave differently after lunch.
So naturally, the next question is this:
How should software actually be organized?
Not just line by line. Not just function by function. I mean the bigger shape of it.
This is where object-oriented programming enters, carrying a clipboard, a blazer, and the strong belief that every noun in your system deserves a little private life.
OOP has been one of the dominant design styles in software for decades. It has helped build serious systems, strange systems, bloated systems, elegant systems, and a truly heroic number of codebases where one class contains 4,000 lines and a comment from 2017 that says temporary fix. It is important. It is useful. It is also not the only way to arrange your thoughts anymore, which is probably healthy for everyone.
So let us talk about what it is, why it caught on, where it still shines, where it starts dressing up ordinary problems in unnecessary ceremony, and why alternative styles keep showing up with folding chairs and better snacks.
What object-oriented programming actually is
Object-oriented programming is a way of organizing software around objects, which combine data and behavior.
In plain English, instead of saying, here is some data over here, and here are a bunch of separate functions that do things to it, OOP says, let us bundle the data and the behavior together so the thing knows how to act.
A BankAccount object might store a balance and also know how to deposit money, withdraw money, and refuse your terrible financial choices. A User object might carry a name, an email, permissions, and the deeply mysterious ability to reset a password only after you have already found your phone.
That bundling is the heart of it.
The classic OOP vocabulary usually brings four terms to the party:
Encapsulation means an object keeps its internals under some control instead of letting outside code rummage through its pockets.
Abstraction means you expose the useful surface without forcing everyone to stare at the plumbing.
Inheritance means one type can build on another type, which sounds elegant right up until your class hierarchy starts resembling medieval nobility.
Polymorphism means different objects can respond to the same request in their own way, which is wonderfully powerful when done well and wonderfully confusing when done like performance art.
Where this came from, and why it got so popular
The big precursor was Simula, and the term object-oriented is generally associated with Alan Kay and the Smalltalk world in the 1970s. If you want the historical rabbit hole, Alan Kay’s early Smalltalk history is the good kind of dangerous.
OOP became especially influential once software got bigger, teams got larger, and everybody realized that just keep adding more functions until the room smells funny was not a sustainable architecture plan. By the 1990s and 2000s, class-heavy thinking was everywhere: enterprise software, desktop applications, major frameworks, design patterns, textbooks, interview prep, and the occasional conference talk delivered by someone standing in front of a diagram that looked like a subway map designed by a committee.
That was its cultural peak.
And honestly, it made sense. Big systems need structure. OOP offered a way to model things, divide responsibilities, and keep related behavior close to the data it affects.
Is it still relevant?
Yes, absolutely.
Just not alone.
OOP is still deeply baked into modern software. If you touch Java, C#, C++, Python, or TypeScript, you are going to meet classes and objects whether you arrived for them or not. The official docs for Python classes, Java classes and objects, C# OOP, and TypeScript classes all make that very plain.
It is also still popular in the broader language ecosystem. The current Stack Overflow 2025 technology survey and the latest TIOBE index both keep object-friendly languages like Java, C#, C++, Python, and TypeScript squarely in the mainstream.
So OOP is not dead.
Its monopoly is down, but its practical relevance is not. In other words, OOP is less the unquestioned emperor than it was in the late 1990s and 2000s, but it is still paying rent in an absurd number of codebases.
Who uses it the most? Pretty much every organization that lives in enterprise software, large back-end systems, Android, .NET, desktop software, or game development. If a company ships serious software in Java, C#, C++, Python, or TypeScript, there is a very good chance objects are already involved, whether anybody is feeling poetic about it or not.
It is just no longer allowed to behave like the only adult in the building.
Why people love it
At its best, OOP gives software shape.
It helps you model systems that naturally contain state and behavior together. A window in a GUI. A character in a game. A bank account. A shopping cart. A document. A network connection. A form field with validation rules and side effects and occasional emotional damage.
It also gives teams useful boundaries. When a class has a clear job and a sane public interface, other parts of the system can use it without having to know all of its private dramas. That lowers the amount of mental clutter floating through the codebase.
Done well, OOP can make large systems easier to extend. You can add a new kind of payment method, a new kind of report, a new kind of shape, a new kind of notification sender, and the rest of the code does not have to throw itself onto the fainting couch.
It also maps nicely to how many humans already think. We like nouns. We like roles. We like little containers of responsibility. OOP shows up and says, excellent, let us make the nouns executable.
Why people roll their eyes at it
Because OOP has a dark side, and its dark side owns a whiteboard.
The trouble starts when developers confuse objects are useful with everything must be an object, even if that object is spiritually just a number wearing a hat.
Then you get elaborate hierarchies, excessive getters and setters, inheritance chains that nobody wants to touch, manager classes managing service classes that coordinate factory classes, and enough abstraction layers to turn a simple task into a guided tour.
A lot of OOP pain comes from over-modeling. People start designing the kingdom before they have built the cottage. The code becomes very organized in the same way a tax form is very organized: technically impressive, emotionally hostile.
This is why OOP has both devoted defenders and exhausted critics. The paradigm itself is not the villain. Decorative bureaucracy is.
Strengths and weaknesses, without the sermon voice
Strengths
OOP is strong when your system has long-lived entities with meaningful state.
It is strong when you need boundaries between parts of a large system.
It is strong when multiple related behaviors belong together.
It is strong when plugging in new variants matters more than shaving every last ounce of indirection.
It is strong in ecosystems that were built around it from day one, which is a polite way of saying that if you are living in .NET, Java-land, game engines, a lot of enterprise software, or UI frameworks, objects are already in the wallpaper.
Weaknesses
OOP is weaker when your problem is mostly data transformation.
It is weaker when inheritance becomes your personality.
It is weaker when the real shape of the problem is a pipeline, a graph, a set of rules, or a bunch of independent functions.
It is weaker when you need raw performance and cache-friendly data layout more than elegant class diagrams.
It is weaker when the team starts building theoretical extension points for futures that never arrive.
A tiny example
Here is a perfectly reasonable little object in Python:
class BankAccount:
def __init__(self, owner, balance=0):
self.owner = owner
self.balance = balance
def deposit(self, amount):
if amount <= 0:
raise ValueError("Deposit must be positive.")
self.balance += amount
def withdraw(self, amount):
if amount <= 0:
raise ValueError("Withdrawal must be positive.")
if amount > self.balance:
raise ValueError("Insufficient funds.")
self.balance -= amount
That is a good fit for OOP because the account has state and behavior that belong together.
But not every problem wants this treatment. If you are just transforming a list of records, calculating totals, parsing a file, or applying a series of rules, a handful of well-named functions can be cleaner, simpler, and far less interested in its own mythology.
What are the alternatives?
This is the fun part, because software has been diversifying its coping mechanisms.
Procedural design says: keep the steps clear, keep the data plain, and use functions to do work. This is often the cleanest choice for straightforward logic.
Functional style says: favor pure functions, immutable data, and predictable transformations. This can make systems easier to reason about, especially when side effects are the gremlins currently chewing through your sanity.
Data-oriented design says: stop romanticizing objects and think about how data is actually laid out and processed, especially in performance-heavy systems like games and simulations.
Component-based design says: instead of deep inheritance trees, assemble behavior from smaller pieces. This is why a lot of modern game and UI systems feel less like family dynasties and more like Lego with consequences.
In real life, most mature codebases are not pure anything. They are mixed economies. A little OOP here, some functional thinking there, plain functions where they help, and one suspicious utility file nobody wants to open after 6 p.m.
So which style is best?
The annoying but correct answer is: the one that matches the shape of the problem.
If you have rich domain entities with state and behavior, OOP can be excellent.
If you have a data pipeline, use a pipeline.
If you have business rules, think carefully about whether classes clarify them or merely give them office furniture.
If performance matters more than conceptual elegance, design around the machine, not around your urge to make everything feel like a tiny society.
Good software design is not about joining a religion. It is about picking a structure that helps the code stay understandable after the third feature request, the second handoff, and the first mildly cursed hotfix.
Is it similar to anything else?
Yes.
OOP overlaps with modular design because both care about boundaries.
It overlaps with abstraction because that is one of its main sales pitches.
It overlaps with component systems because both try to organize behavior into manageable pieces, though components are usually much less interested in inheritance drama.
It overlaps with functional design at the practical level too, because real programmers steal good ideas from wherever they find them. A modern codebase can absolutely use objects for stateful domain concepts and pure functions for calculations without bursting into flames.
Does it work well with AI?
Surprisingly well, with one important warning label.
AI code tools are often comfortable generating class-based code because OOP patterns are common, recognizable, and heavily represented in training data. When your codebase has clear entities, explicit interfaces, and readable method names, assistants can usually follow the trail.
The warning is that AI is also extremely willing to over-engineer. Give it a mildly boring problem and it may propose three interfaces, two abstract base classes, a factory, a strategy, and a deeply sincere explanation of why your toaster deserves dependency injection.
So yes, OOP works well with AI.
It also gives AI more furniture to rearrange, which is not always the same thing.
What tech stack does it work with?
Almost all of them, at least to some degree.
It is most at home in Java, C#, C++, Python, TypeScript, Kotlin, Swift, and plenty of framework-heavy ecosystems built around classes, components, and structured domain models.
It also plays nicely with databases, APIs, web backends, desktop apps, game engines, and mobile apps. In other words, OOP is less a niche and more a recurring architectural accent.
What tools work best with it?
IDEs tend to love OOP because objects give tools something to navigate. Refactoring tools, autocomplete, type systems, debuggers, test frameworks, static analyzers, and diagramming tools all become more useful when the code has clear types and interfaces.
This is one reason OOP flourished in enterprise environments. Tooling loves structure almost as much as management does.
How much is this going to cost you?
Usually very little in licensing.
A lot of the languages and tools involved are free.
The real cost is in complexity. OOP becomes expensive when you build more abstraction than the problem can afford. Then you pay in onboarding time, debugging time, meeting time, and that special kind of staring-at-the-code silence where nobody wants to be the first to ask why AbstractBaseEventFactoryManager exists.
So the cost is rarely money for OOP.
The cost is how clever did we get.
Is it the subject of any famous art?
Not really, unless somebody finally puts UML diagrams in a museum and calls it Administrative Cubism.
OOP has inspired famous books, famous arguments, famous conference talks, and famous regret.
That is close enough for software.
The real lesson here
Object-oriented programming matters because it teaches an important truth: software design is about choosing how ideas should live together.
That is bigger than classes.
OOP is one very influential answer to that question. Not the only answer. Not always the best answer. But still a valuable one, especially once you stop treating it like a universal solvent for every programming inconvenience.
Learn it well enough to use it on purpose.
Learn the alternatives well enough to know when not to.
That is when design stops being cargo cult architecture and starts becoming judgment.
And judgment, unfortunately, is the one thing no framework can install for you.
If you want the full staircase that led here, the CS 101 side includes Episode 1: What Is CS 101?, Episode 2: Programming Fundamentals Part 1: Variables and Conditionals, Episode 3: Loops and Functions, Episode 4: Algorithmic Thinking, Episode 5: Data Structures, and Episode 6: History, Debugging, and Problem Solving.
The CS 102 climb so far includes Episode 7: Recursion and Problem Decomposition, Episode 8: Complexity and Efficiency, Episode 9: Memory and the Machine, Episode 10: Files, Input, and Output, Episode 11: Modular Design and Abstraction, Episode 12: Testing and Reliability, and Episode 13: State, Bugs, and Program Behavior.
If this installment made your architectural instincts feel either validated or mildly attacked, follow along for more, and tell me in the comments which coding style has helped you the most: object-oriented, procedural, functional, or whatever got production back online before lunch.
Art Prompt (Conceptual Art): A vast white architectural interior transformed into a serene field of rigorous geometry, where crisp graphite lines, arcs, and measured bands sweep across walls, floor, and ceiling with mathematical grace. Let the composition feel immersive and spacious, with black, charcoal, slate, and pale cream tones arranged in disciplined balance, interrupted by a few soft planes of muted ochre and dusty blue. The surfaces should feel hand-drawn yet exact, with faint chalk texture, subtle pressure variation, and the elegant tension of human imperfection inside a rule-based system. Keep the mood contemplative, cerebral, and quietly ecstatic, as if pure structure has become a form of breathing.
Video Prompt: Inside a luminous white gallery, thin charcoal lines begin appearing on walls and floor as if drawn by an invisible hand, then unfold into sweeping arcs, grids, and measured bands that ripple outward in perfect rhythm. Let the camera glide, pivot, and rise through the space as geometry blossoms around it, with graphite dust, soft chalk texture, and faint shadows giving the motion a tactile physicality. Build visual momentum through snapping alignments, elegant reveals, and hypnotic expansions of pattern, ending in a fully transformed room that feels calm, intelligent, and spellbinding.
For music, try Awash — Hammock or A Meaningful Moment Through a Meaning(less) Process — Stars of the Lid.