In Defense of Object-Oriented Programming

Zvonimir Rudinski
4 min readAug 31, 2021

Object-oriented programming has been around for a very long time. Earliest mentions that I could find are dating back to late 50s and early 60s.

It really blew up with languages like Java, C++ and C# (languages that are still very popular today) and in my opinion is nowhere close to dying.

Don’t get me wrong — there isn’t anything wrong with writing functional code either. It all boils down to your use case. You probably wouldn’t go object oriented when writing a simple calculator app. It’s a major overkill in that case.

Lately I’ve noticed object-oriented programming is getting a lot of negative rep and in my opinion it’s not always justified so I decided to play the devil’s advocate a bit and bring up some points where I think OOP really shines.

Working with databases

When working with more complex data structures like database tables you can still write functional code and raw SQL queries but in my opinion you’re bound to shoot yourself in the foot at some point. In the age of modern ORMs there isn’t really a need to write raw SQL unless you’re really squeezing out that last drop of performance from your apps.

Representing database entities like objects is a natural thing to do in my opinion.

While you can still very much write functional code that works with databases, you’re still going to want to make it more abstract and entity-agnostic to avoid code duplication — but it always feels like a hack to me and I would rather define my database tables using classes.

Working with similar entities

Now I can see why some people think this is a bad thing. Sometimes you can accidentally over-engineer and end up with lot of unused boilerplate code (I’m looking at you frameworks) but when done correctly it can really make your code look more organized.

For example if I’m working with two or more entities that mostly do same things instead of creating multiple functions or a function with multiple if statements I think creating a base class and overriding it’s methods down the line is a much better approach. It makes your code reusable and more clean if done correctly.

If I want to change some behavior I just need to change a specific class method instead of going through multiple functions just to make sure everything is glued properly. By using inheritance I eliminate lots of redundant code.

Debugging

When dealing with bugs, using OOP can make your life easier. If you’re having issues with a specific object you’ll know exactly where to look and you just have to change that specific class instead of going down the rabbit hole of multiple functions. Using encapsulation you’re also protected from changing the data you’re not supposed to and it adds an extra layer of security which saved me more times that I’d like to admit.

Modularity

Now this is one of the biggest pros of OOP I could think of. Splitting up your code in multiple reusable chunks that can be extended very easily is a very big bonus in my book. If I want to add another piece to an already existing system I don’t have to go through the trouble of making sure it works by testing multiple function calls. I could just write a test for that specific entity and make sure it works properly.

These are just some advantages of OOP that I could think of but let me know in the comments what you think is the biggest pro/con of OOP and thanks for reading.

--

--

Zvonimir Rudinski

A full-stack web developer with years of experience under his belt. My interests include: programming, science, music and the occult.